Re: [alsa-devel] Pls don't require exclusive Alsa audio device access, use snd_pcm_dmix_open ()
thomas schorpp wrote:
thomas schorpp wrote:
since dmix is enabled by libasound2 by default for cards not supporting h/w mixing.
skype can access the audio device using snd_pcm_dmix_open () if other app has already opened it, ekiga throws error msgboxes.
skype 5089 skype mem CHR 116,24 7792 /dev/snd/pcmC0D0c skype 5089 skype mem CHR 116,16 7784 /dev/snd/pcmC0D0p kio_file 5422 schorpp 0r CHR 1,3 956 /dev/null kio_uiser 6025 schorpp 0r CHR 1,3 956 /dev/null iceape-bi 30161 schorpp mem CHR 116,16 7784 /dev/snd/pcmC0D0p iceape-bi 30161 schorpp 0r CHR 1,3 956 /dev/null iceape-bi 30161 schorpp 66r CHR 116,33 7473 /dev/snd/timer iceape-bi 30161 schorpp 67u CHR 116,16 7784 /dev/snd/pcmC0D0p
y tom
hmm. takeback. future removal warning in alsa lib doc. well for experiments (in ptlib plugin):
Index: sound_alsa.cxx
--- sound_alsa.cxx (Revision 18763) +++ sound_alsa.cxx (Arbeitskopie) @@ -344,13 +344,15 @@ } }
- if (snd_pcm_open (&os_handle, real_device_name, stream,
SND_PCM_NONBLOCK) < 0) {
- if (snd_pcm_open (&os_handle, real_device_name, stream,
SND_PCM_NONBLOCK) < 0)
- PTRACE (1, "ALSA\tOpen Failed");
- return FALSE;
- }
- else
- snd_pcm_nonblock (os_handle, 0);
- if (_snd_pcm_dmix_open (&os_handle, real_device_name, snd_config_t*
root, snd_config_t* sconf, stream, SND_PCM_NONBLOCK) < 0) {
PTRACE (1, "ALSA\tOpen Failed");return FALSE;}
else
snd_pcm_nonblock (os_handle, 0);/* save internal parameters */ device = real_device_name;
i cant find any sample code for the missing params, google is full of alsa user issues ;)
y tom
@alsa devs any hints?
On Wed, 28 Nov 2007, thomas schorpp wrote:
- if (_snd_pcm_dmix_open (&os_handle, real_device_name, snd_config_t*
root, snd_config_t* sconf, stream, SND_PCM_NONBLOCK) < 0) {
Uff. It's really wrong. What you're trying to do? Simply use 'default' device name for snd_pcm_open() which should have defined dmix access if required. And don't forget to allow specify (force) ALSA device name to users if someone wants a special setup.
Jaroslav
----- Jaroslav Kysela perex@perex.cz Linux Kernel Sound Maintainer ALSA Project
Jaroslav Kysela wrote:
On Wed, 28 Nov 2007, thomas schorpp wrote:
- if (_snd_pcm_dmix_open (&os_handle, real_device_name, snd_config_t*
root, snd_config_t* sconf, stream, SND_PCM_NONBLOCK) < 0) {
Uff. It's really wrong. What you're trying to do? Simply use 'default' device name for snd_pcm_open() which should have defined dmix access if required. And don't forget to allow specify (force) ALSA device name to users if someone wants a special setup.
+1 Dmix should not be enforced... this can be handled at a lower level.... e.g. with dmix configured in alsa config or by using pulseaudio instead of dmix (my preferred solution so I can switch from my internal speakers to my usb headset should I plug it in mid-call).
Col.
Colin Guthrie wrote:
Jaroslav Kysela wrote:
On Wed, 28 Nov 2007, thomas schorpp wrote:
- if (_snd_pcm_dmix_open (&os_handle, real_device_name, snd_config_t*
root, snd_config_t* sconf, stream, SND_PCM_NONBLOCK) < 0) {
Uff. It's really wrong. What you're trying to do? Simply use 'default' device name for snd_pcm_open() which should have defined dmix access if required. And don't forget to allow specify (force) ALSA device name to users if someone wants a special setup.
well, this is only draft code ;) ekiga uses the openh323.org ptlib alsa plugin and this thing blocks all other apps device access or gets blocked if another app like iceape is already on the device, twinkle has the same issue and this gets really on my nerves, cause i need to restart iceape to get the device free for telephony again, always :[
skype uses snd_pcm_dmix_open() (seen it in a bugtrace) and has no such problems.
i cant hardcode the devicename since it is selected and passed down by ekiga, the original code does:
- if (snd_pcm_open (&os_handle, real_device_name, stream, SND_PCM_NONBLOCK) < 0)
so i must define the dmix access in ekiga, it seems not be defined implicitely?
+1 Dmix should not be enforced... this can be handled at a lower level.... e.g. with dmix configured in alsa config or by using pulseaudio instead of dmix (my preferred solution so I can switch from my internal speakers to my usb headset should I plug it in mid-call).
Col.
alsa docs say dmix config files are no longer neccessary?
maybe the old (2.6.18 kernel) driver for this device has more bugs than not reinitializing mixer setting after acpi resume: 00:1f.5 Multimedia audio controller: Intel Corporation 82801CA/CAM AC'97 Audio Controller (rev 01) Subsystem: IBM ThinkPad T23 (2647-4MG) or A30/A30p (2652/2653)
snd_intel8x0 30332 1 snd_ac97_codec 83104 1 snd_intel8x0 snd_ac97_bus 2400 1 snd_ac97_codec snd_pcm_oss 38368 0 snd_mixer_oss 15200 1 snd_pcm_oss snd_pcm 68676 3 snd_intel8x0,snd_ac97_codec,snd_pcm_oss snd_timer 20996 1 snd_pcm snd 47012 8 snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer soundcore 9248 1 snd snd_page_alloc 9640 2 snd_intel8x0,snd_pcm
ii libasound2 1.0.15-2 ALSA library
cat: /proc/asound/I82801CAICH3: Is a directory cat: /proc/asound/card0: Is a directory 0 [I82801CAICH3 ]: ICH - Intel 82801CA-ICH3 Intel 82801CA-ICH3 with CS4299 at 0x1c00, irq 5 0: [ 0] : control 16: [ 0- 0]: digital audio playback 24: [ 0- 0]: digital audio capture 25: [ 0- 1]: digital audio capture 33: : timer 0 snd_intel8x0 cat: /proc/asound/oss: Is a directory 00-01: Intel ICH - MIC ADC : Intel 82801CA-ICH3 - MIC ADC : capture 1 00-00: Intel ICH : Intel 82801CA-ICH3 : playback 1 : capture 1 cat: /proc/asound/seq: Is a directory G0: system timer : 4000.000us (10000000 ticks) P0-0-0: PCM playback 0-0-0 : SLAVE P0-0-1: PCM capture 0-0-1 : SLAVE P0-1-1: PCM capture 0-1-1 : SLAVE Advanced Linux Sound Architecture Driver Version 1.0.12rc1 (Thu Jun 22 13:55:50 2006 UTC).
i will try the recent kernel maybe this solves things...
thx tom
At Wed, 28 Nov 2007 17:01:47 +0100, thomas schorpp wrote:
+1 Dmix should not be enforced... this can be handled at a lower level.... e.g. with dmix configured in alsa config or by using pulseaudio instead of dmix (my preferred solution so I can switch from my internal speakers to my usb headset should I plug it in mid-call).
Col.
alsa docs say dmix config files are no longer neccessary?
The behavior depends on the name string passed to snd_pcm_open(). If you open the PCM with "default", the alsa-lib takes an approriate configuration for multi-playback and automatic conversions. But, if app opens with other strings like "hw" or "plughw", then it means that it's an exclusive access. dmix cannot be involved with that.
Takashi
Takashi Iwai wrote:
At Wed, 28 Nov 2007 17:01:47 +0100, thomas schorpp wrote:
+1 Dmix should not be enforced... this can be handled at a lower level.... e.g. with dmix configured in alsa config or by using pulseaudio instead of dmix (my preferred solution so I can switch from my internal speakers to my usb headset should I plug it in mid-call).
Col.
alsa docs say dmix config files are no longer neccessary?
The behavior depends on the name string passed to snd_pcm_open(). If you open the PCM with "default", the alsa-lib takes an approriate configuration for multi-playback and automatic conversions. But, if app opens with other strings like "hw" or "plughw", then it means that it's an exclusive access. dmix cannot be involved with that.
Takashi
thx guys. using the "default" device in ekiga audio device config solved it :)
skype 5218 skype mem CHR 116,24 8292 /dev/snd/pcmC0D0c skype 5218 skype mem CHR 116,16 8284 /dev/snd/pcmC0D0p iceape-bi 5277 schorpp 0r CHR 1,3 1107 /dev/null ekiga 5411 schorpp mem CHR 116,16 8284 /dev/snd/pcmC0D0p ekiga 5411 schorpp mem CHR 116,24 8292 /dev/snd/pcmC0D0c ekiga 5411 schorpp 0r CHR 1,3 1107 /dev/null ekiga 5411 schorpp 63r CHR 116,33 7972 /dev/snd/timer ekiga 5411 schorpp 64u CHR 116,24 8292 /dev/snd/pcmC0D0c ekiga 5411 schorpp 67r CHR 116,33 7972 /dev/snd/timer ekiga 5411 schorpp 68u CHR 116,16 8284 /dev/snd/pcmC0D0p
many thx, Takashi. ALSA rocks!
BTW:
http://www.xs4all.nl/~mfnboer/twinkle/manual.html#sys_audio
"NOTE:The ALSA default device should only be used for the ring tone and/or speaker. It is not recommended to use the ALSA default device for the microphone as it gives poor quality."
this is not the case. fine here.
http://www.xs4all.nl/~mfnboer/twinkle/faq.html#alsa_no_sound
"There can be many reasons why you do not get sound. With ALSA, a common problem is the lack of a proper /etc/asound.conf file. Here is a copy of my asound.conf."
twinkle guys should update their docs.
y tom
participants (4)
-
Colin Guthrie -
Jaroslav Kysela -
Takashi Iwai -
thomas schorpp