Hello, Yes I think you are right ; forcing the audio device in your case leads to a bug.
select_audio_device is supposed override the deviceId when it is forced, but I guess that the "const char *" stops this from working. Maybe you can try and patch it this way (making sure that when we get out of select_audio_device, the deviceId has been changed) Like you get with your patch you should get something like (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phmedia-alsa.c:316) alsa_stream_open: (name: alsa: in=0 out=0, rate: 16000, framesize: 640) (confirming that the alsa driver is given an alsa name) After that you should look on line (122) of phmedia-alsa: rc = snd_pcm_open(&handle, name, type, 0); It seems to me that using "name" is a bug here And this would be why it tells you "unable to open < in=0 out=0> pcm device" The snd_pcm_open (a native alsa primitive if I understand it right) should be given a device name that is compatible with it. The principle in phapi is that "alsa:in=0 out=0" Is a shortcut device id string. This string is parsed to get the in= and the out= values. These values are used as native driver ids. You can also look at the portaudio impl : phmedia-portaudio.c (192). It has been coded in yet another way (!) I hope this will help you in your quest ! Jerome -----Message d'origine----- De : Didier LINK [mailto:[EMAIL PROTECTED] Envoyé : mercredi 24 janvier 2007 01:25 À : Jerome WAGNER Cc : 'Wengophone Devel' Objet : RE: [Wengophone-devel] Native Alsa support on Linux Le mardi 23 janvier 2007 à 20:03 +0100, Jerome WAGNER a écrit : > Hello Didier, > > >(debug) 18:07:01 static std::list<AudioDevice, > >std::allocator<AudioDevice> > AudioDeviceManager::getOutputDeviceList(): > >output device found=(default) /dev/dsp OSS > > Means that the GUI is binded on OSS. Ok, I see, it's disturbing to initialize all the devices type at once. > > Do you have DBG_DYNA_AUDIO_DRV logs when you start a call ? They should > mention the usage of the ALSA backend because of the FORCE_xxx thing. The tests with portaudio works with a call, not a very good sound at all but it work. With the Alsa backend I've no sound and the log is: (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phaudiodriver.c:39) registering audio driver of kind "alsa" ... (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phaudiodriver.c:58) ...registration ok (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phaudiodriver.c:39) registering audio driver of kind "pa" ... (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phaudiodriver.c:58) ...registration ok (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phaudiodriver.c:39) registering audio driver of kind "null" ... (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phaudiodriver.c:58) ...registration ok (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phaudiodriver.c:39) registering audio driver of kind "file" ... (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phaudiodriver.c:58) ...registration ok (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phmedia-alsa.c:310) alsa_stream_open: (name: pa:IN=0 OUT=0, rate: 16000, framesize: 640) (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phmedia-alsa.c:94) alsa_dev_open: (name: pa:IN=0 OUT=0, rate: 16000, framesize: 320) (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phmedia-alsa.c:132) unable to open <pa:IN=0 OUT=0> pcm device: Aucun fichier ou répertoire de ce type (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phmedia-alsa.c:310) alsa_stream_open: (name: pa:IN=0 OUT=0, rate: 16000, framesize: 640) (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phmedia-alsa.c:94) alsa_dev_open: (name: pa:IN=0 OUT=0, rate: 16000, framesize: 320) (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phmedia-alsa.c:132) unable to open <pa:IN=0 OUT=0> pcm device: Aucun fichier ou répertoire de ce type It's a problem in the name of the device, I've used "alsa: in=0 out=0" in the variable PH_FORCE_AUDIO_DEVICE but the result is a mix between initialization of Alsa with portaudio parameters. In a gdb session I see that the deviceId is picked from a phcfg structure: ph_msession_start(s, phcfg.audio_dev) in wifo/phapi/phapi-old.c:3395 I think in this context of forcing the device driver it's a bug :) I've tried the attached patch but it's just a step further, the phlogger.log contain : (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phmedia-alsa.c:316) alsa_stream_open: (name: alsa: in=0 out=0, rate: 16000, framesize: 640) (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phmedia-alsa.c:94) alsa_dev_open: (name: alsa: in=0 out=0, rate: 16000, framesize: 320) (DBG_DYNA_AUDIO_DRV:/home/didier/temp/openwengo-ng/wengophone-2.1/wifo/phapi /phmedia-alsa.c:132) unable to open < in=0 out=0> pcm device: Aucun fichier ou répertoire de ce type I think the change will be made in the function select_audio_device(const char *deviceId) in phmedia-audio.c:2070 If this function return the deviceId after test the env vars, I think the use of this vars can be more transparent for all drivers. What do you think about this enhancement ? Sorry for the long message and thanks for your attention. Best regards. Didier Link _______________________________________________ Wengophone-devel mailing list [email protected] http://dev.openwengo.com/mailman/listinfo/wengophone-devel
