Re: [Alsa-devel] usb-audio
Am Donnerstag, 30. Oktober 2003 20:46 wurde geschrieben: At Thu, 30 Oct 2003 13:42:14 +0100, hmm, really weird. meanwhile, i rewrote snd_pcm_linear_convert() without goto trick. could you try the attached patch? ... you don't really want to know... Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 22147)] 0x0fd41564 in snd_pcm_linear_conv_xx12_xx21 ( src=0x104e4000 Address 0x104e4000 out of bounds, dst=0x30c28590 , src_step=4, dst_step=4, frames=7835) at pcm_linear.c:303 303 DEF_CONV(conv_xx12_xx21,l_conv_xx12_xx21); (gdb) bt #0 0x0fd41564 in snd_pcm_linear_conv_xx12_xx21 ( src=0x104e4000 Address 0x104e4000 out of bounds, dst=0x30c28590 , src_step=4, dst_step=4, frames=7835) at pcm_linear.c:303 #1 0x0fd429f4 in snd_pcm_linear_convert (dst_areas=0x104d1f18, dst_offset=0, src_areas=0x7fffcf10, src_offset=0, channels=2, frames=16384, convidx=0) at pcm_local.h:362 #2 0x0fd435a0 in snd_pcm_linear_write_areas (pcm=0x0, areas=0x1, offset=2147471120, size=12, slave_areas=0x0, slave_offset=1140885572, slave_sizep=0xfdb408c) at pcm_linear.c:722 #3 0x0fd3f808 in snd_pcm_plugin_write_areas (pcm=0x2, areas=0x7fffcf10, offset=0, size=273489688) at pcm_plugin.c:365 #4 0x0fd35d94 in snd_pcm_write_areas (pcm=0x104db890, areas=0xfd41554, offset=0, size=273489688, func=0) at pcm.c:6206 #5 0x0fd3fc14 in snd_pcm_plugin_writei (pcm=0x104db600, buffer=0x30c28590, size=273489688) at pcm_plugin.c:436 #6 0x0fd2ec3c in snd_pcm_writei (pcm=0x0, buffer=0x0, size=0) at pcm_local.h:368 #7 0x10078718 in outputaudio () #8 0x1007837c in outputaudio () #9 0x1002ed74 in main () Niklas -- --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] usb-audio
At Fri, 31 Oct 2003 09:23:02 +0100, Niklas Werner wrote: Am Donnerstag, 30. Oktober 2003 20:46 wurde geschrieben: At Thu, 30 Oct 2003 13:42:14 +0100, hmm, really weird. meanwhile, i rewrote snd_pcm_linear_convert() without goto trick. could you try the attached patch? ... you don't really want to know... yes, i do want to know that :) at least, it spots out the real segfault place. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 22147)] 0x0fd41564 in snd_pcm_linear_conv_xx12_xx21 ( src=0x104e4000 Address 0x104e4000 out of bounds, dst=0x30c28590 , src_step=4, dst_step=4, frames=7835) at pcm_linear.c:303 303 DEF_CONV(conv_xx12_xx21,l_conv_xx12_xx21); that's it: the source address is bogus. i should have asked you to check that... Takashi --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] aureal driver compile problem and patch
At Thu, 30 Oct 2003 22:12:57 -0500, Carolyn and Eric Hathaway wrote: After making these modifications (see patch below), the vortex driver compiled with no unresolved symbols on my system, and is working great. thanks! applied to cvs. Takashi --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: CMI8738-MC6 surround40 plugin on 4 SP systems]
At Thu, 30 Oct 2003 12:42:39 -0500, Marcel wrote: I've been trying to finetune my cmipci for several weeks now. And this is the best way I've been able to get transparent operation with various audio material: stereo, mono, 4.0, 5.1. The main problem being no surround sound iif Exchange DAC setting was not set, and sound on the rear speakers only if it was. ah, this might be true. does it happen both on 4.0 and 5.1 outputs? i don't remember that it's necessary for 5.1 at the last time i tested. I think the following patch should be considered. It puts the surround sound on the rear speakers, where it should be when using the plugin surround40, and on front speakers in normal stereo/mono mode. I've been testing it for several days now and it seems better than the original CMI8738-MC6.pcm. looks fine. i'll add it. perhaps we should simply remove this control from user and handle internally for the MC6 chip. thanks, Takashi --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] alsa-driver-0.9.8, jack, cmipci
(I sent this earlier twice but forgot to subscribe and then gave wrong email address,
so earlier two are pending moderator approval. Please ignore those, and sorry).
Hi,
Alsa-driver-0.9.8 doesn't work properly for full duplex operation with jack-0.80 and
spdif from a cmedia 8738. (I had been using alsa 0.9.2, before, and it worked just
fine). Here's what happens:
starting jack with
jackd -d alsa -d cmipci
causes the D/A Valid light on my external DA converter (a midiman flying cow) to go
off, the levels to get pegged, and i can hear what sounds like spdif in my speakers.
I quit jack, the flying cow remains in it's weird loop, and i do something like
starting and quitting esd to reset it.
if i only do capture (jackd -d alsa -d cmipci -C) it seems fine, but of course no
output.
if i don't use .asoundrc (jackd -d alsa -d hw:0) the output is fine, but jack can't
read any input. Note: recording without jack using arecord doesn't work with hw:0,0,
but arecord -Dhw:0,2 does (as expected)
Since 0.92 works with the same jack version (0.80), I decided to post here first. I'm
more than willing to send along any other info to help resolve this problem.
my .asoundrc:
pcm.cmipci {
type hw
card 0
device 2
}
ctl.cmipci {
type hw
card 0
}
my /proc/asound/devices: (device 3 is the dummy driver)
1: : sequencer
0: [0- 0]: ctl
8: [0- 0]: raw midi
18: [0- 2]: digital audio playback
26: [0- 2]: digital audio capture
17: [0- 1]: digital audio playback
16: [0- 0]: digital audio playback
24: [0- 0]: digital audio capture
4: [0- 0]: hardware dependent
33: : timer
32: [1- 0]: ctl
43: [1- 3]: raw midi
42: [1- 2]: raw midi
41: [1- 1]: raw midi
40: [1- 0]: raw midi
64: [2- 0]: ctl
72: [2- 0]: raw midi
96: [3- 0]: ctl
112: [3- 0]: digital audio playback
120: [3- 0]: digital audio capture
Thanks a bunch!
Jon
-
Jonathan Kraut
NYC
[EMAIL PROTECTED]
--- End of Forwarded Message
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Broken pipe when starting pcm
Hi Whenever I turn on xrun detection, setting stop_threshold to buffer size instead of -1, snd_pcm_start refuses to work. The exit message to do with broken pipe. I figured it might be caused by an empty buffer, so I fill it with silence before start. snd_pcm_avail_update confirms this (zero frames available), but it makes no difference. This happens with both my cards, nForce2 onboard and RME DIGI9636. If someone could point out the cause of this, I'd truly appreciate it. If it matters I am running a development kernel, 2.6.0 test9-mm1. Thanks Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: CMI8738-MC6 surround40 plugin on 4 SP systems]
* Takashi Iwai ([EMAIL PROTECTED]) wrote: At Thu, 30 Oct 2003 12:42:39 -0500, Marcel wrote: I've been trying to finetune my cmipci for several weeks now. And this is the best way I've been able to get transparent operation with various audio material: stereo, mono, 4.0, 5.1. The main problem being no surround sound iif Exchange DAC setting was not set, and sound on the rear speakers only if it was. ah, this might be true. does it happen both on 4.0 and 5.1 outputs? i don't remember that it's necessary for 5.1 at the last time i tested. With surround40 plugin, 4 speakers, yes it's needed for both 4.0 and 5.1 material. Applications such as mplayer or xine will remix 5.1 material to 4 channels. For 6 speakers systems, I really don't know. perhaps we should simply remove this control from user and handle internally for the MC6 chip. I agree. Its usage is confusing and may results in improper operation --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH] serial-u16550 driver. Fixes buffer blocking bug
At Thu, 30 Oct 2003 13:33:37 -0800,
Steve deRosier wrote:
Takashi,
Thanks for your response. I've addressed your issues below. Let's
discuss this and if necessary I'll modify my fix.
1. Move all checks of buffer overflow and such to the
actual buffer write and read routines. This makes
the buffer routines more robust and encaspulates buffer
opperations better.
the check in the caller may be still needed for the multi-bytes write
(e.g. for switching the port). otherwise, the port-switch command
can be mixed and messed up when the device is accessed concurrently.
I thought about this, but decided it's not a large issue since it is
mitigated by the natural operation of the driver.
For normal opperation: As this is called with interupts off, the
process can't be interupted. The function doesn't return until after
we've drained the snd_rawmidi_transmit(), and if we do decide to insert
a f5... msg, we do the whole msg before we can return. So, no issue
durring normal opperation. So concurrent access doesn't apear to be a
large issue.
yes, normally it's ok. the problem would be only the full-buffer
state.
If buffer gets full: Yes, it is possible for an f5... msg to get
interupted. BUT, I don't see this as a large problem. On return to
normal opperation (ie. the buffer begins draining again), the proper
port-switch command will be written in correctly when the port gets
switched, or in the next three seconds, whichever comes first. Perhaps
some data gets sent to the wrong port, but it autocorrects very quickly.
While this condition technically is possible, I haven't seen it happen
in practice, and even if it does it would correct itself quickly. For
another mittigating factor, please see my answer to #2 below.
If you're still concerned about this, I have an alternate fix that would
keep a check, but not interfeare with opperation.
2. Always try to send data to the buffers. Don't interupt
normal opperation of the algoritim because buffers are full.
This was what was actually causing the data to be left in
rawmidi and thus causing it to lock up. This is helped
by moving the buffer size checks into the routines.
this is the questionary behavior.
the fact that the local buffer is full means that the transfer doesn't
work. so, it is quite correct behavior that rawmidi blocks the
further write (in blocking mode), i think. and, it should return
-EAGAIN in non-blocking mode.
or, at least, we can make the behavior selectable: abandon or block.
Well, the driver already was trying to opperate in the mode where it was
abandoning bytes, it was just doing a bad job of it. All I did was fix
it so it actually abandoned all bytes that didn't fit in the buffers.
Before it was grabbing a byte from snd_rawmidi_transmit() and if no room
was in the buffer it would break out of the while(1) loop. So,
basically it would abandon the first byte on its execution, but leave
some data there for later. This caused a problem with rawmidi's buffers
seeming to back up and eventually hanging up the driver (recoverable
only via reopening the device).
basically, the data should NOT be abandoned as long as it can be
held. the current code is not good from this perspective.
it should be something like:
while (snd_rawmidi_transmit_peek(substream, byte, 1) == 1) {
if (! writable())
break;
write_byte(byte);
snd_rawmidi_transmit_ack(substream, 1);
}
The program (call it pdr) we have using this device operates in blocking
mode. So, if things worked properly, pdr would attempt to write the
midi msg, and the snd_seq_event_output() just wouldn't return until it
was able to send the data. That would be fine. BUT, if we physically
disconnect the serial cable from the device, after awhile, the buffer in
serial-u16550.c fills up, then one byte is retrieved from
snd_rawmidi_transmit() (and then discarded by the driver) for every
three bytes put into the rawmidi buffers, these buffers fill up and
eventually cause the lockup of the driver, all while never reporting a
problem back to pdr (snd_seq_event_output() seems not to block even
though we're in blocking mode).
in this case, the operation is blocked because it's really blocked.
sure, it doesn't report errors because it's just the blocking
behavior. the driver doesn't detect the disconnection, and it simply
waits until the next transfer is available.
(snip)
However, if we want different behavior, let me know how to do this. I
was able to fix the problem here, without digging further into the
rawmidi code or even further up the chain. Frankly I'm not educated
enough on that code to safely mess with it. To handle a blocking
mode, the driver would need some way to properly communicate it is full
to rawmidi. This could be either some method to
[Alsa-devel] ALSA CVS: breaks with 2.4 kernel
The alsa-kernel/core/sound.c file references the linux/device.h header file, but this header does not exist under Linux 2.4. Deleting the reference fixes the build. Cheers, Chris Want to chat instantly with your online friends? Get the FREE Yahoo! Messenger http://mail.messenger.yahoo.co.uk --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Broken pipe when starting pcm
On Fri, 31 Oct 2003 18:27:16 +0100, Arve Knudsen [EMAIL PROTECTED] wrote: Hi Whenever I turn on xrun detection, setting stop_threshold to buffer size instead of -1, snd_pcm_start refuses to work. The exit message to do with broken pipe. I figured it might be caused by an empty buffer, so I fill it with silence before start. snd_pcm_avail_update confirms this (zero frames available), but it makes no difference. This happens with both my cards, nForce2 onboard and RME DIGI9636. If someone could point out the cause of this, I'd truly appreciate it. If it matters I am running a development kernel, 2.6.0 test9-mm1. Thanks Arve Knudsen Ok, was able to track it down to snd_pcm_prepare. I already tested the stream state, so I knew the stream was in the prepared state before I called snd_pcm_prepare myself. However I would never have thought that calling snd_pcm_prepare before snd_pcm_start could cause problems, isnt this the standard procedure (preparing before start)? At least commenting out the prepare call before starting, makes the problem go away. I see I also have to fill the buffer before snd_pcm_start (or deal with broken pipe), I thought a silence size equal to boundary and silence threshold of 0 would cause the buffer to be automatically silenced (judging from the docs)? Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Broken pipe when starting pcm
On Sat, 01 Nov 2003 01:10:27 +0100, Arve Knudsen [EMAIL PROTECTED] wrote: On Fri, 31 Oct 2003 18:27:16 +0100, Arve Knudsen [EMAIL PROTECTED] wrote: Hi Whenever I turn on xrun detection, setting stop_threshold to buffer size instead of -1, snd_pcm_start refuses to work. The exit message to do with broken pipe. I figured it might be caused by an empty buffer, so I fill it with silence before start. snd_pcm_avail_update confirms this (zero frames available), but it makes no difference. This happens with both my cards, nForce2 onboard and RME DIGI9636. If someone could point out the cause of this, I'd truly appreciate it. If it matters I am running a development kernel, 2.6.0 test9-mm1. Thanks Arve Knudsen Ok, was able to track it down to snd_pcm_prepare. I already tested the stream state, so I knew the stream was in the prepared state before I called snd_pcm_prepare myself. However I would never have thought that calling snd_pcm_prepare before snd_pcm_start could cause problems, isnt this the standard procedure (preparing before start)? At least commenting out the prepare call before starting, makes the problem go away. I see I also have to fill the buffer before snd_pcm_start (or deal with broken pipe), I thought a silence size equal to boundary and silence threshold of 0 would cause the buffer to be automatically silenced (judging from the docs)? Awww, looks like I cheered to early. Once I compile with optimizations or try to restart because of xruns, I'm hit by the same error. Completely at a loss here, maybe I should just accept the defeat :\ Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
