[MPlayer-dev-eng] audio_out.c question

[Mitch Golden]

I do seem to have started a pretty spirited discussion when I brought this 
subject up.  As I said, I hope to be able to make (an at least minor) 
improvement with making the messaging changes that Rich and I discussed 
below.

I also have the following comments/questions:

*) As others have said, I ran into problems not because I was trying to 
play two videos or sound streams at once, but rather because another app 
played a system sound when I had had mplayer paused, and then mplayer 
crashed when I tried to unpause.  I am not an unsophisticated user - I 
have been using sound on Linux for years, and am well aware with the 
issues of turning on and off the various sound daemons.  I do a lot of 
sound editing with Audacity (and I am an occasionally-active developer of 
it), and I normally log in with the artsd controller on the screen so I 
can deal with all the contention for /dev/dsp.  Still, it's a PITA, and 
for non-sophisticated user who wants it to "just work", I want to help 
improve the messages so they can understand what is going on, and not see 
unnecessary popups.

*) As for the idea of using the system speaker for system sounds - I 
believe that you can configure KDE to do this, but it wouldn't be too 
good if you are either using the system remotely or are on a multiuser 
system.  (Do all PCs even have a built-in speaker nowadays?  Yes, I 
remember the talking system speaker on DOS.)

*) Rich has persuaded me that there might be some pretty good reasons not 
to use alsa when a video stream is involved, especially on slower 
hardware.  I am still not getting what the problem is with preferring alsa 
in the case of an audio-only stream.  If mplayer goes through alsa when it 
can, it will at least play better with other apps.

A couple of other questions:

*) A question: Windows can have multiple applications on these self same 
single-voice soundcards.  How does it do it without something like alsa 
mixing the streams?

*) I notice that the config file defines a C macro for /dev/dsp but then 
there a bunch of places where the string "/dev/dsp" appears in the code. 
Shouldn't those be replaced with the macro?

   - Mitch

On Thu, 23 Mar 2006, Rich Felker wrote:

> On Wed, Mar 22, 2006 at 10:09:59PM -0500, Mitch Golden wrote:
>> I would point out is that it's not artsd that takes control of /dev/dsp,
>> but rather that no two applications can have /dev/dsp open at once - not
>> even two separate instances of mplayer.  In that regard, the thing that is
>> broken is OSS really.
>
> No, it's an underlying limitation of the hardware. If you want
> multiple programs playing audio at the same time, get hardware that
> supports this. In sane users' minds this is useless though. Why would
> you need to play and mp3 and a movie at the same time? You'll just
> mess up your ability to hear either.
>
>> As I understand it, that issue was one of the major
>> reasons that alsa was written.
>
> ALSA's dmix is much more broken. It does resampling and mixing behind
> the user's back, forking behind the calling program's back which
> introducing all sorts of bugs, and breaks A/V sync.
>
>> Is there any issue with using alsa in preference to OSS, at least for
>> audio only files?
>
> Yes. ALSA will use dmix, etc. crap. The OSS emulation layer is immune
> to all these userspace hacks and thus is not buggy.
>
>> As you say, artsd is not necessary and doesn't improve
>> anything, so keeping it at the bottom of the list is fine.  Does alsa
>> cause the desync problem as well?  My understanding is that it's
>> implemented at the kernel level just as OSS is.
>
> Without dmix it's kernel level only, but then you lose the only
> advantage you wanted.
>
>> I could also improve the message when it does crash on unpause, so that
>> it's clear that what happened is that some other application has grabbed
>> the audio device.
>
> Yes this would be a nice change.
>
> Rich
>
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> http://mplayerhq.hu/mailman/listinfo/mplayer-dev-eng
>