- Alsa-devel - mailman.alsa-project.org

Re: [alsa-devel] Audio on Linux is a mess
by Marek Vasut 20 Oct '08

20 Oct '08

You got what you paid for. Maybe if you change your attitude and supply some information, someone might consider looking in your issue, othervise it would be a problem since I forgot my crystal ball back at home. On Monday 20 of October 2008 16:41:45 Fred . wrote: > Yeah, fix the Linux audio so that if an application behaves wrong, or > does something stupid, then after I close the application, the system > should be silent. > It shouldn't continue make sound even after I quit the application. > And PulseAudio shouldn't crash because one application did something > even if it was stupid. > > On Mon, Oct 20, 2008 at 8:35 AM, Marek Vasut <marek.vasut(a)gmail.com> wrote: > > On Friday 17 of October 2008 15:24:20 Fred . wrote: > >> ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect: > >> Timeout ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to > >> connect: Timeout AL lib: alsa.c:344: Could not open playback device > >> 'default': Connection refused AL lib: oss.c:179: Could not open > >> /dev/dsp: Device or resource busy File > >> "/var/lib/python-support/python2.5/pyglet/media/drivers/openal/__init__. > >>py" , line 340, in driver_init_device = alc.alcOpenDevice(device_name) > >> > >> Audio on Linux is a mess. > >> I launch an Python script that uses audio then it breaks, and when the > >> Python script is closed, I still hear the audio skipping and repeating > >> like, > >> "kakakakakakaka" in infinite loop. > >> And PulseAudio seems to be frozen. > >> Then I kill PulseAudio and finally the audio noise stops. > >> > >> Oh, and I heard OpenAL downsamples stereo to mono on Linux due to a bug. > >> > >> Whole audio on Linux is just a big mess. > > > > Please behave yourself. > > Is there any way we can help you (which I doubt, but ...)? > > > >> _______________________________________________ > >> Alsa-devel mailing list > >> Alsa-devel(a)alsa-project.org > >> http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

2 1

[alsa-devel] Audio on Linux is a mess
by Fred . 20 Oct '08

20 Oct '08

ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect: Timeout ALSA lib pulse.c:272:(pulse_connect) PulseAudio: Unable to connect: Timeout AL lib: alsa.c:344: Could not open playback device 'default': Connection refused AL lib: oss.c:179: Could not open /dev/dsp: Device or resource busy File "/var/lib/python-support/python2.5/pyglet/media/drivers/openal/__init__.py", line 340, in driver_init_device = alc.alcOpenDevice(device_name) Audio on Linux is a mess. I launch an Python script that uses audio then it breaks, and when the Python script is closed, I still hear the audio skipping and repeating like, "kakakakakakaka" in infinite loop. And PulseAudio seems to be frozen. Then I kill PulseAudio and finally the audio noise stops. Oh, and I heard OpenAL downsamples stereo to mono on Linux due to a bug. Whole audio on Linux is just a big mess.

3 2

[alsa-devel] No pcm device?
by John Kacur 20 Oct '08

20 Oct '08

I'm not sure if the hardware I have makes this problem simple for me, or difficult, because it seems to differ from other ASoC code. Basically, I have a i2s as transport, connected to max5556 driving the output. (and a few other chips related to amplification and muting) There is however no sound card, thus no PCM device. Now the question is how to proceed? In other words what kind of minimal PCM layer do I need if any? Thanks

2 7

[alsa-devel] [PATCH] snd-sbxfi: implement Master volume control
by William Pitcock 20 Oct '08

20 Oct '08

Unfortunately, the X-Fi does not have a hardware master volume control, so we have to create a virtual master and bind all playback controls to it. This patch depends on the patch that renames Master to PCM. Signed-off-by: William Pitcock <nenolod(a)sacredspiral.co.uk> --- sound/pci/sbxfi/sbxfi.c | 30 ++++++++++++++++++++++++++++++ 1 files changed, 30 insertions(+), 0 deletions(-) diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index 3e99a97..d8b32aa 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -1685,15 +1685,45 @@ static struct snd_kcontrol_new mixers[] __devinitdata = { }, }; +/* list of controls to attach to the master volume control. */ +static const char *slave_vols[] __devinitdata = { + "PCM Playback Volume", +}; + static int __devinit sbxfi_create_mixer(struct sbxfi *chip) { int i, err; + struct snd_kcontrol *vmaster; for (i = 0; i < ARRAY_SIZE(mixers); i++) { err = snd_ctl_add(chip->card, snd_ctl_new1(&mixers[i], chip)); if (err < 0) return err; } + + /* + * Unfortunately, it seems that there is no master control, unlike + * on the emu10k1 series, so we create a virtual master, and bind + * our playback controls to it. + */ + vmaster = snd_ctl_make_virtual_master("Master Playback Volume", NULL); + if (vmaster == NULL) + return -ENOMEM; + + /* attach the master to the card, and attach all slaves to it. */ + snd_ctl_add(chip->card, vmaster); + for (i = 0; i < ARRAY_SIZE(slave_vols); i++) { + struct snd_kcontrol *slave; + struct snd_ctl_elem_id sid; + + memset(&sid, 0, sizeof(sid)); + strlcpy(sid.name, slave_vols[i], 44); /* XXX this should be a constant defined somewhere */ + sid.iface = SNDRV_CTL_ELEM_IFACE_MIXER; + + if ((slave = snd_ctl_find_id(chip->card, &sid)) != NULL) + snd_ctl_add_slave(vmaster, slave); + } + return 0; } -- 1.5.5.4

3 6

[alsa-devel] Microphone array using ALSA
by Ola Benderius 20 Oct '08

20 Oct '08

Hi! http://en.wikipedia.org/wiki/Microphone_array Would it be possible to use several USB soundcards in GNU/Linux using ALSA to build a microphone array? I have searched the Internet but haven't found any straight answers. What I have read is that it might be hard to sync the captured streams even if it would be possible. So, three questions. 1. Is it theoretically possible? 2. Can it be done using several USB soundcards? 3. Do you know of any code or project in this area as it is? Think this might be a necessary advancement for the future, the applications are many. Even Windows Vista has support for it. Other thoughts, comments? Regards, Ola

1 0

[alsa-devel] ALSA SOC in the ARM linux kernel - pxa2xx-pcm oops on invalid dma_ch.
by Oliver Ford 20 Oct '08

20 Oct '08

Hi, I had been working on a kernel for the iPAQ 21x series (PXA310 based with a WM9713) which I had originally (June 08) based on arm.linux.org.uk's git tree with wolfsonmicro.com/linux-2.6-asoc/asoc-v2-dev merged in. Recently (last week) I tried to pull the latest changes from arm.linux.org.uk and got too many conflicts in the ALSA SOC code, the mainline kernel code seems to have been cleaned up a lot compared to asoc-v2-dev. Due to this I'm now working from the ALSA SOC code as it comes in arm.linux.org.uk. This mostly works but I'm having trouble with oopses due to invalid DMA channels in pxa2xx-pcm.c. Is this the right place to ask about this, if so I'll post the details here (which I already posted on the arm-linux mailing list). Is there a branch on wolfsonmicro.com that would be closer to what is now in the main kernel? Thanks, Oliver Ford

2 1

[alsa-devel] davinci_request_dma()
by John Kacur 20 Oct '08

20 Oct '08

I'm looking for a little bit more help reading the SOC code. In particular, I'm reading davinci-pcm.c, and function davinci_pcm_dma_request, which makes two calls to davinci_request_dma. However, when I grep for davinci_request_dma, the only places I can find it are in davinci_pcm_dma_request itself! [jkacur@mydcore linux-2.6.26]$ grep -rn davinci_request_dma * sound/soc/davinci/davinci-pcm.c:143: ret = davinci_request_dma(prtd->params->channel, prtd->params->name, sound/soc/davinci/davinci-pcm.c:150: ret = davinci_request_dma(PARAM_ANY, "Link", Either I'm missing something, or this code wouldn't even compile. I would appreciate any help in understanding this. Thank you.

2 10

[alsa-devel] snd-xfi info
by James Courtier-Dutton 20 Oct '08

20 Oct '08

Hi, Trying to answer some question raised by comments in the current code. 1) The card should be able to DMA to anywhere in a 64-bit address space. It is set to 32bit DMA by default. A bit has to be set to turn on 64-bit. 2) GPIOs > GPIOs > SB046x / SB067x / SB0760 > Bit In/Out Def Use > 0: Not used > 1: Out 0 Reset DAC > 2: Out 0 Int_Drv_SpdifBypas (1 = Bypass) > 3: Not Used > 4: Not Used > 5: Out 0 In_Drv_DAC_SR (0=48kHz, 1=96kHz) > 6: Out 0 Back_Bracket_Lineouts_Mute (0=Mute) > 7: Out 0 Mic/Line select( 0=Line, 1=Mic) > 8: Out 1 Digital IO Select (0 = Digital, 1 = Analog) > 9: In - Int_Drv_Headphone_Det (1 = headphone detected) > 10: Not used > 11: In - FP_Headphone_Det (0 = headphone detected) > 12: Not used > 13: In - LineOut3 detect (1 = jack inserted) > 14: In - LineOut2 detect (1 = jack inserted) > 15: In - LineOut1 detect (1 = jack inserted) > > SB073x > Bit In/Out Def Use > 0: Not used > 1: Out 0 Reset DAC > 2: Out 0 Int_Drv_SpdifBypas (1 = Bypass) > 3: Not Used > 4: Not Used > 5: Out 0 In_Drv_DAC_SR (0=48kHz, 1=96kHz) > 6: Out 0 Back_Bracket_Lineouts_Mute (0=Mute) > 7: Out 0 Mic/Line select( 0=Line, 1=Mic) > 8: In - Line/Mic In detect (0 = jack inserted???) > 9: In - Int_Drv_Headphone_Det (1 = headphone detected) > 10: Not used > 11: In - FP_Headphone_Det (0 = headphone detected) > 12: In - Digital Out detect (1 = detected) > 13: In - LineOut3 detect (1 = jack inserted) > 14: In - LineOut2 detect (1 = jack inserted) > 15: In - LineOut1 detect (1 = jack inserted) > > Vista compatible > Bit In/Out Def Use > 0: In - FP_Linein_detect (1 = jack inserted) > 1: Out 0 Reset DAC > 2: Not Used > 3: Not Used > 4: Not Used > 5: Not Used > 6: Out 0 Back_Bracket_Lineouts_Mute (0=Mute) > 7: Out 0 Mic/Line select( 0=Line, 1=Mic) > 8: In - Line/Mic In detect (1 = jack inserted???) > 9: In - FP_MicIn_Detect (1 = jack inserted) > 10: Not used > 11: In - FP_Headphone_Det (0 = headphone detected) > 12: In - LineOut4 detect (1 = detected) > 13: In - LineOut3 detect (1 = jack inserted) > 14: In - LineOut2 detect (1 = jack inserted) > 15: In - LineOut1 detect (1 = jack inserted) > > SB055x > Bit In/Out Def Use > 0: In - FP_Mic_detect (1 = jack inserted) > 1: Out 0 Mute all analog inputs(0=Mute) > 2: Out 0 ADC_Gain (0=boost off, 1=boost on) > 3: Out 1 SPDIFOut0 Unmute (0=Mute, 1=Unmute) > 4: Out 0 FP_Mic_select( 1=FPMic) > 5: Out 0 Ext_Drv_DAC_SR (0=48kHz, 1=96kHz) > 6: Out 0 Lineout1_Mute (1=Mute) > 7: Out 0 Mic power on(1=Power on) > 8: Out 0 Digital IO Select (0 = Analog, 1=Digital) > 9: Out 0 Mic_sw(0=Line/Aux, 1=FP/BP Mic) > 10: Not used > 11: In - FP_Headphone_Det (0 = headphone detected) > 12: Out 0 AuxMicLine sw(0=MicLine) > 13: In - LineOut3 detect (1 = jack inserted) > 14: In - LineOut2 detect (1 = jack inserted) > 15: In - LineOut1 detect (1 = jack inserted) > > Card Family > SB046x / > SB067x / > SB076x > = > Subsystem ID > 0x0021 > 0x0023 > 0x0024 > 0x0025 > 0x0026 > 0x0027 > 0x0028 > 0x002A > 0x002B > 0x002C > 0x002D > 0x002E > 0x0032 > 0x0033 > > Card Family > SB073x > = > Subsystem ID > 0x0029 > 0x0031 > > Card Family > SB055x > = > Subsystem ID > 0x0022 > 0x002F > > Card Family > Vista Compatible Hardware > = > Subsystem ID > Range from 0x6000 to 0x6FFF > More later James

2 2

Re: [alsa-devel] 20K1 PCI bars, and mode switching info.
by James Courtier-Dutton 20 Oct '08

20 Oct '08

Vedran Miletić wrote: > Takashi added UAA mode to hda-intel driver with patch_creative.c, > IIRC. Why would this be necessary? > In time xfi mode will have far more features than the UAA mode. E.g. hardware mixing of over 64 channels at the same time. The UAA mode has no hardware mixing and handles only a few channels.

2 1

Re: [alsa-devel] Backported sbxfi driver (UNTESTED!)
by Takashi Iwai 19 Oct '08

19 Oct '08

At Fri, 17 Oct 2008 14:16:38 +0400, The Source wrote: > > Takashi Iwai пишет: > > At Fri, 17 Oct 2008 14:01:55 +0400, > > The Source wrote: > > > >> Takashi Iwai пишет: > >> > >>> At Fri, 17 Oct 2008 13:58:20 +0400, > >>> The Source wrote: > >>> > >>> > >>>> Takashi Iwai пишет: > >>>> > >>>> > >>>>> At Fri, 17 Oct 2008 11:57:08 +0400, > >>>>> The Source wrote: > >>>>> > >>>>> > >>>>> > >>>>>> Takashi Iwai пишет: > >>>>>> > >>>>>> > >>>>>> > >>>>>>> At Thu, 16 Oct 2008 22:18:07 +0400, > >>>>>>> The Source wrote: > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>>>> Ok. OpenAL with alsa also seem to cause problems. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> In both cases, check the period_size and buffer_size values (shown in > >>>>>>>>> the kernel message, or /proc/asound/card0/pcm0p/sub0/hw_params). > >>>>>>>>> And, try to aplay with these parameters, whether you get the similar > >>>>>>>>> problem. > >>>>>>>>> > >>>>>>>>> % aplay -v --period-size=xxx --buffer-size=yyy foo.wav > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Takashi > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> I'm sorry, but any attemp to play file with ossplay results in complete > >>>>>>>> system hang with error: > >>>>>>>> unable to handle NULL ponter dereference at address > >>>>>>>> 0000000000000008.....(hang, no more output). > >>>>>>>> I tried many wav formats. So I can't get error log or period and buffer > >>>>>>>> sizes, sorry. > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>> Can anyone confirm to reproduce Oops with OSS apps (ossplay)? > >>>>>>> > >>>>>>> I'm wondering whether this has anything to do with the capture. > >>>>>>> Can you record the sound, and change the capture mixer element properly? > >>>>>>> > >>>>>>> > >>>>>>> thanks, > >>>>>>> > >>>>>>> Takashi > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> I checked mplayer. It uses period size 1024 instead of 4096 and 16384 > >>>>>> buffer size (default). Sound is choppy (sound pauses is more frequent > >>>>>> when rate is lower). > >>>>>> However an attempt to play the same file with the same period and buffer > >>>>>> sizes with aplay results in complete system hang. > >>>>>> > >>>>>> > >>>>>> > >>>>> OK, that looks like a problem. Looks like the timer resolution can be > >>>>> short like that, or something racy in the timer handling. > >>>>> > >>>>> Can you check whether this happens with XXX_SYSTEM_TIMER, too? > >>>>> > >>>>> Or, does the patch below avoid the problem, at least? > >>>>> > >>>>> > >>>>> thanks, > >>>>> > >>>>> Takashi > >>>>> > >>>>> diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c > >>>>> index 26a6cd3..5ceb228 100644 > >>>>> --- a/sound/pci/sbxfi/sbxfi.c > >>>>> +++ b/sound/pci/sbxfi/sbxfi.c > >>>>> @@ -277,6 +277,7 @@ static void sbxfi_rearm_timer(struct sbxfi *chip, int ticks) > >>>>> #else > >>>>> > >>>>> #define MAX_TICKS ((1 << 13) - 1) > >>>>> +#define MIN_TICKS 1000 /* FIXME: really so? */ > >>>>> > >>>>> static void sbxfi_init_timer(struct sbxfi *chip) > >>>>> { > >>>>> @@ -287,6 +288,8 @@ static void sbxfi_set_timer(struct sbxfi *chip, int ticks) > >>>>> LOG(2, "SET TIMER TICKS = %d\n", ticks); > >>>>> if (ticks > MAX_TICKS) > >>>>> ticks = MAX_TICKS; > >>>>> + else if (ticks < MIN_TICKS) > >>>>> + ticks = MIN_TICKS; > >>>>> sbxfi_write(chip, TIMR, ticks | TIMR_IE | TIMR_IP); > >>>>> } > >>>>> static void sbxfi_stop_timer(struct sbxfi *chip) > >>>>> > >>>>> > >>>>> > >>>>> > >>>> After patch: > >>>> > >>>> Without system timer: > >>>> > >>>> aplay --period-size=1024 96000_16_Stereo.wav > >>>> Plays fine > >>>> > >>>> aplay --period-size=1024 22050_16_Mono.wav > >>>> BUG: unable to handle kernel NULL pointer dereference at 0000000000000008 > >>>> Hang > >>>> > >>>> With system timer: > >>>> > >>>> aplay --period-size=1024 96000_16_Stereo.wav > >>>> Superglitch. Each sample is played many times before advancing to next one. > >>>> > >>>> aplay --period-size=1024 22050_16_Mono.wav > >>>> Instant reboot. > >>>> > >>>> > >>> Just to be sure: you don't enable XXX_CONT_RATE, right? > >>> It's known to be buggy, so disabled as default now. > >>> > >>> > >>> Takashi > >>> > >>> > >>> > >> It is disabled for me too. > >> > > > > And the patch didn't help? > > > > > > Takashi > > > > > Only 96000Hz Stereo without system timer plays fine after patch. Please elaborate? You mean 22.5k still doesn't work with the patch? Does 22.5kHz ever work with other parameters? It'd be really helpful if you get the full Oops log... The patch affects only the emu20k1 timer. The system timer stuff isn't touched by it. The reboot implies that it's unlikely the timer but the driver wrote something wrong (unless you have the set up that the kernel traps and automatically reboot). But, it's nothing but a wild guess at this point. Anyway, I updated the driver code a bit again. Please check the latest one. thanks, Takashi

4 8