I'm sorry for taking so long to follow up on this. My computer broke and stayed that way for a very long time, and I've just recently begun to dig this up again.
Anyway, if you're still willing to help me, here are my findings. Clemens Ladisch <[EMAIL PROTECTED]> writes: > Fredrik Tolf wrote: > > The most annoying thing is that sounds seem to be serialized, ie. if > > one process plays something through the OSS DSP device, any other > > process that also tries to play through the OSS DSP device blocks > > until the first process is done. An strace revealed that it is the > > write() calls that are blocking. ps also reveals that the kernel is > > sleeping in down(). To make things stranger, it seems that only > > "short" streams are blocking. When I have, for example, an MP3 playing > > through /dev/dsp, other processes can play sounds simultaneously (but > > those that play short streams still block each other). What the > > difference between a "short" and a "long" stream is, I can't really > > determine, though. > > Are you using the same program for play "short" and "long" streams? Normally, yes. mpg321 with -o oss (-o alsa doesn't work since I don't have libalsa for libao; I'll try to get my hands on it) for almost all "long" streams, and sox for short streams. However, I have tried piping mpg321's output into sox, and it makes no difference whatsoever. > Is there a difference in the buffer size given to write() (as seen by > strace) between "short" and "long" streams? Well, mpg321 does have a strange buffer size (4608 bytes), but since I tried piping it to sox instead, it doesn't seem to matter. > > I have only tried with the OSS DSP, since I don't know how to play > > PCM sound natively with ALSA. I tried some of the pcm* devices in > > /dev/snd, but none yielded any sound output. > > Use "aplay something.wav", or "aplay -Dplughw:X,Y something.wav", > where X is the card number and Y the device number (see "aplay -l" for > a list). I did that, and to my surprise it yielded the same results, ie. multiple aplay processes playing "short" streams blocked each other while "long" streams wouldn't affect anything at all. I would have thought that it was something in the OSS layer, but it seems to be a driver issue. Btw., is there any "direct" way of natively playing streams in ALSA, ie. like /dev/dsp in OSS? Fredrik Tolf ------------------------------------------------------- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php _______________________________________________ Alsa-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-user
