emu10k1 ALSA/jack problem

emu10k1 ALSA/jack problem

[jamesmstone]

Dear All,

I am currently working on an audio program (aldrin) which uses
libbzub driver
http://trac.zeitherrschaft.org/zzub/browser/trunk/src/libzzub/driver.cpp
for accessing the sound card. Libzzub, in turn uses rtaudio
version 3.03, which is part of the libzzub source tree.

The problem arises when I am running a jack server using my
sblive, but specifying the default interface (hw:0).

On startup, a vast number of xruns are generated (>200) and jack
either falls over, or the computer almost completely locks up.

This appears to be caused by rtaudio probing the alsa devices
whilst jack is running. Interestingly, if I specify a sub-device
(hw:0,3), or the integrated sound card (intel), no xruns are
generated.

I am wondering if this problem is arising because of a bug in the
emu10k1 driver, or a problem with the way rtaudio probes alsa
devices, or because it is a bad idea to probe alsa devices while
they are being used by jack???

Best wishes,

James

Re: emu10k1 ALSA/jack problem

[Takashi Iwai]

At Fri, 10 Aug 2007 12:10:45 +0100,
jamesmstone@gmail.com wrote:
> 
> Dear All,
> 
> I am currently working on an audio program (aldrin) which uses
> libbzub driver
> http://trac.zeitherrschaft.org/zzub/browser/trunk/src/libzzub/driver.cpp
> for accessing the sound card. Libzzub, in turn uses rtaudio
> version 3.03, which is part of the libzzub source tree.
> 
> The problem arises when I am running a jack server using my
> sblive, but specifying the default interface (hw:0).
> 
> On startup, a vast number of xruns are generated (>200) and jack
> either falls over, or the computer almost completely locks up.
> 
> This appears to be caused by rtaudio probing the alsa devices
> whilst jack is running. Interestingly, if I specify a sub-device
> (hw:0,3), or the integrated sound card (intel), no xruns are
> generated.
> 
> I am wondering if this problem is arising because of a bug in the
> emu10k1 driver, or a problem with the way rtaudio probes alsa
> devices, or because it is a bad idea to probe alsa devices while
> they are being used by jack???

It's hard to tell.  In some cases, it's rahter a hardware setup
(e.g. assining another PCI slot helps) and in some cases it's a
software problem. 

It's possible that concurrent access to hw:0,0 may hold long locks.
Speciying hw:0,3 means that you're using another PCM device (the
multi-channel PCM), so the lock is likely specific to the PCM stream.
One difference between HD-audio and emu10k1 here is that emu10k1 has
multiple (sub)streams while HD-audio has a single stream.  Thus,
opening the same device will result in a blocking on HD-audio while
emu10k1 gives the next available substream.


Takashi