[alsa-devel] emu10k1 ALSA/jack problem
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
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
participants (2)
-
jamesmstone@gmail.com
-
Takashi Iwai