alsa plays only one sound at once

[maverick6664]

Hi all,

Some time ago, alsa began not to accept multiple pcm sound sources. I forgot when and what I did then.....anyway it's like OSS.... Until then, it accepts two or more pcm sources; for ex, playing audicious and youtube at once.

TIA

[eccerr0r]

Not entirely sure about this, but I thought that if you use legacy OSS emulation in ALSA, you still are limited to one source. Are all your applications using ALSA libraries instead of OSS?

Audacious should be using ALSA properly (check to make sure you're not using OSS output driver), I'm not so sure about youtube (which is using Adobe-Flash, not sure what that is using nowadays...)

[PaulBredbury]

Show the apps currently using audio:

fuser -fv /dev/snd/* /dev/dsp* 2>/dev/null

ALSA's emulation of OSS bypasses dmix. So in a nutshell, you do not want any apps using /dev/dsp*

Edit: Changed flags to -fv, to hopefully show the app name

[maverick6664]

Thanks for your replies.

I'm sure audacious uses ALSA output plugin. As for Youtube(adobe-flash), I'm not sure.only audacious, "fuser -v /dev/snd/* /dev/dsp* 2>/dev/null" returns "8639 8639" (only audacious) and " 8639 8872 8639"(both audacious and youtube. Does this mean both processes use /dev/dsp?

Thanks.

EDIT: while only youtube is playing and audacious is turned on, it says "device busy" error. Doesn't it mean audacious uses alsa?

[PaulBredbury]

Try -fv instead of -v

The fuser flags are nuts
fuser only shows the app names if run directly in a shell, and not if run from an alias or script.

[aCOSwt]

while only youtube is playing and audacious is turned on, it says "device busy" error. Doesn't it mean audacious uses alsa?

Youtube can only use Alsa !default.

To achieve what you wish, you need a sound server (such as Jack)
(or fiddle a dmix plugin in your asound.conf but I dislike this method)

[Dorsai!]

Why do you dislike dmix?

Dmix should normaly be turned on by default. But as it is a userspace library it needs to be installed. Did you install alsa-lib alsa-plugins and alsa-utils?

If it should work but doesn't (like with spdif) you can activate it manually like this (where you have to edit the device name "hw:0,4" and the hint of course):

/etc/asound.conf

Code: Select all

pcm.!default {
    type plug
    slave {
        pcm "dmixer"
        }
    rate_converter "samplerate_best"
    hint {
        show on
        description "SPdif Out"
    }
}

pcm.dmixer  {
    type dmix
    ipc_key 1024
    ipc_perm 0666
    slave {
       pcm "hw:0,4"
       format S32_LE
       rate 44100
    }
}

[maverick6664]

Then, what /etc/asound.conf looks like in my case?

Code: Select all

$ cat /proc/asound/cards  
 0 [Loopback       ]: Loopback - Loopback
                      Loopback 1
 1 [CMI8738        ]: CMI8738-MC6 - C-Media CMI8738
                      C-Media CMI8738 (model 55) at 0xe400, irq 22

I don't use SPdif, and use rate 44100.

but when I used alsa for the first time, I didn't do such a complicated thing.....

EDIT:I did all written in http://www.gentoo.org/doc/en/alsa-guide.xml Any caveat?

[maverick6664]

I switched my card to the integrated Intel HD, but alsaconf doesn't detect it....

Code: Select all

$ cat /proc/asound/cards
 0 [Loopback       ]: Loopback - Loopback
                      Loopback 1
 1 [Intel          ]: HDA-Intel - HDA Intel
                      HDA Intel at 0xf9ffc000 irq 40

EDIT: In order to change default devices, I also edited .asoundrc to

Code: Select all

pcm.!default {
  type hw
  card Intel
}

ctl.!default {
  type hw
  card Intel
}

Now audacous and youtube work independently, (not at once )

[PaulBredbury]

type hw

"hw" means hardware - you have deliberately disabled dmix.

Why don't you look at the dozens of examples that google provides?

Another example - my ~/.asoundrc

Ignore alsaconf, it's rubbish.

[aCOSwt]

Why do you dislike dmix?

Mainly because of this :

Code: Select all

buffer_size 16384

Default dmix buffer size is huge. And I have never been statisfied when trying to lower its value with the buffer_size statement. Particularily when resampling is needed.
This leads to an unacceptable (for me) latency.
One can achieve the same with a sound server with considerably smaller buffers.

BTW, PaulBredbury, why do you explicitely resample to 48K ? I thought that resampling to 48K was the default behavior for dmix.

[PaulBredbury]

explicitely resample to 48K

Haha, I've switched between 44100 and 48000 quite a few times, trying to find a reason for preferring one over the other.

Making the rate explicit, helps to reduce confusion, and make it easy to change.

I'd kept with 44100 for months, and decided to change to 48000 today, because 48000 causes less confusion to the poor ALSA newbies, some of whom have hardware which doesn't play nicely with 44100 it seems. That's about the only reason I've found for preferring one over the other. (My ears can't notice the resampling to 48000 of songs.)

As for the buffer_size, again it's an experiment to see what is the best combination with period_time, period_size, and buffer_time. These values are not set in stone, and if a lower buffer works well for you, then great - use it.

I play first-person shooters with my config, with sound latency which is perfectly fine for me - and I'm a fussy bugger when it comes to things like frames per second, vertical vsync (must be on) and audio latency. So, what problem do you experience, in what apps? Be specific.

[Dorsai!]

Default dmix buffer size is huge. And I have never been statisfied when trying to lower its value with the buffer_size statement. Particularily when resampling is needed.
This leads to an unacceptable (for me) latency.
One can achieve the same with a sound server with considerably smaller buffers.

But at the cost of some incompatibility, cpu power and configuration time. Also, to really achieve an improvement he would have to use a realtime kernel which again has it's own disadvantages for normal desktop use.

Don't get me wrong, I use Jack myself for Audacity, Ardur, Rosegarden and LMMS together with qsynth, but for listening to music, system sounds and watching youtube videos, jack is overkill.

When using the good resampler from libsamplerate ("rate_converter "samplerate_best"") no difference should be audible. But as I am often listening to DTS Waves (which are 44100 and may not be resampled because it would corrupt the datastream) over SPdif 44100 was the rate to go for. BTW: DMix handles this signal bit-perfect, or else I would hear static instead of music.

@Maverick: It should most probably look like this then:

Code: Select all

pcm.!default { 
    type plug 
    slave { 
        pcm "dmixer" 
        } 
    rate_converter "samplerate_best" 
    hint { 
        show on 
        description "DMix Stereo Out" 
    } 
} 

pcm.dmixer  { 
    type dmix 
    ipc_key 1024 
    ipc_perm 0666 
    slave { 
       pcm "hw:1,0" 
       format S32_LE 
       rate 48000 
    } 
}

A complete alternative to ALSA (with also far lower software mixing latency that might even satisfy production needs) OSS4 is an Option:
http://www.opensound.com/
I used it a long time myself and it is really easy to install and use via the oss overlay.

Edit: You also will have to either delete your ~/.asoundrc or use what I wrote above in it. ~/.asoundrc overrides /etc/asound.conf.

[aCOSwt]

for listening to music, system sounds and watching youtube videos, jack is overkill.

I agree. Even more if applications used for that such a flash-player are not jack-api capable. And at the end of the say, as the vast majority of the associated materials do not care a damn of audio/video sync... who cares about latency...

So, what problem do you experience, in what apps? Be specific.

When trying Mbrola Voices (~22K) => Espeak => Portaudio => dmix + rate 96K => Device 1 in // with Other_apps => Jackd (96K) => Device 2
I never managed to put all this in sync, stopped fiddling and incidentally implemented resampling in portaudio when I realized dmix' buffering was one of the most significant culprit.
BTW, taking your parameters (period_size 512, periods 8, buffer_size 16384, rate 48K) (That are fine by themselves indeed) we reach a theoretical latency of ~85ms.
This is indeed noticeable. Maybe the following image can give an impression of the result :
- Corresponding to two performers distant from about 30 meters...
- About the time for a semi-quaver in any classical presto...
A Huge latency is not per se a problem. I can adapt easily as long as it is fixed. I would be pleased to exchange a +-~20ms variable latency against a =85ms fixed latency. The problem with latency induced by buffers is that this latency is not fixed. And the more important the theoretical value is, the more important the variance is.

Apologizes to maverick6664 for having somehow hijacked his thread ! I -> ]

[Dorsai!]

I don't understand why a latency coming from a buffer is not fixed? If it would "oscellate" the audio rate would have to change.
Data should leave the buffer exactly at "rate" and come into the buffer at exactly the rate the application puts it there. But I dont really know how the last part (Application/ALSA interface) works. Can you explain the reason for this?

I myself do not have a buffer related video sync problem at all, because I use AC3/DTS Passthrough for dvd etc., effectively bypassing DMIX. For all other video applications (youtube etc.) I really dont care about latency. My receiver then has some of its own latency (decoding the surround signal, DSP etc.), but that I can be corrected using a fixed negative delay available in most video players.

[PaulBredbury]

theoretical latency of ~85ms.

I dunno how important the word "theoretical" is there.

In my tests, the infamous Adobe Flash (spit) sometimes doesn't play if the buffer is low (5000-6000 ish).

I've gone back to 44100 in my public example, and with buffer_size 8192 - let's see if that causes a problem. I think I raised it to 16384 to see if it helped crackling audio in the other infamous app Skype (also closed-source, so we can't see what crappy audio code it has ). IIRC Doom3 actually requires 8192, but I use a separate PCM for Doom3 anyway.

[maverick6664]

Thank you all. I try .asoundrc and if everything fails, I will put up with the current one.

Thank you very much!

[aCOSwt]

I don't understand why a latency coming from a buffer is not fixed? If it would "oscellate" the audio rate would have to change.
Data should leave the buffer exactly at "rate" and come into the buffer at exactly the rate the application puts it there.

You are correct.
But... I was not meaning that the latency varies during the playing. I meant that the mathematical variance of the latency differs depending on the buffer size.
Practically speaking under my nonRT-sources system :

- Have an application sending sound directly (not through dmix) to one sound device.
- Have another application running concurrently which, thanks to the snd_aloop driver, inputs from the looped-back device associated to the sound device mentioned above and outputs on another sound device through dmix.
- Plug an oscilloscope on both devices output. Then measure the time shift between both signals.

Make several measurements Ai for a given dmix' buffer size value
Increase significantly (x4) the buffer size value and make several other measurements Bi

What I want to underline (without being capable to explain though) is that Max(Bi) - Min(Bi) > Max(Ai) - Min(Ai)

Which leads to many annoying synchronization problems when having apps which, such as skype, espeak... and... mine , do not output sound permanently. => The buffer is emptied before it eventually restarts being filled.

[Dorsai!]

I see your point. And one possible explanation for that phenomenon is, that there is a slight difference in time (varying with cpu usage at that moment) between the buffer being filled by your program and emptied by the soundcard. Thats the whole use of the buffer anyway... to compensate for that cpu usage.

And also I see your argument now why it can not be compensated fully by a fixed delay in the using applications. Though, for most purposes it can be greatly limited by removing the static component of the delay middling out the varying delay to (Max - Min)/2

In that case +-20ms would be a delay (which btw. is far under 1 Frame in Video) I could live with very well for convenience's sake. For production applications jack is a better option anyway.

Did you try OSS4 already? It uses kernelspace mixing (vmix) with outstanding soundquality and latency. If it would support my card a little better (kept plopping everytime a stream opened) I would still use it. It's really easy to install through the oss overlay too.

[whig]

I had issues with concurrent audio sources. Software solutions were not up to it. For me the solution was having a sound card that does hardware mixing. Here's a list. Shooter games were noticeably smoother on my quad core desktop. Worth it definitely.

[aCOSwt]

Did you try OSS4 already?

No !
Two years ago I gave up trying to make a freeBSD based DAW because freeBSD is OSS only and OSS did not support MIDI.
Alsa being my first motivation for moving to Linux, I happily forgot all about OSS since then and know nothing of OSS4.
If it supports MIDI and you report that it is of higher quality than Alsa, my interest might wake up.

For me the solution was having a sound card that does hardware mixing.

I second you. I would even say that hardware mixing is compulsory for who targets live performances.
And... to tell you the exact truth... my external hardware-only mixer is... not yet decommissioned... though I would dream it is.

[Dorsai!]

Before you do spend some time figuring it out the hard way:

OSS4 has while compatible to the old oss interface its own advanced api (including midi), BUT that is not compatible with common alsa synths even software ones like the virtual one timidity uses. The only option at the moment is to use fluidsynth with its wave output bypassing the oss interface. It worked well for me with qjackctl, qsynth and rosegarden though and I never tried external midi hardware.

With opensolaris gone the developement of oss4 (which is unlike ALSA platform independent) seemed to halt though...