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

[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

[alsa-devel] Digidesign Mbox 2 Mini
by Mark Hills 19 Oct '08

19 Oct '08

I have been trying to use a Digidesign Mbox 2 Mini (USB) without success, but with some positive signs. The device is detected. From the software side, playback appears to work -- both aplay and mplayer push audio to somewhere (no crashes, and at the correct rate). But there is no sound from any of the outputs. Recording is not so good. It does not error or crash, but arecord hangs and creates a 44 byte file containing the WAV header. In a test program, snd_pcm_readi() does not return and strace waits on poll(). I found two threads on alsa-devel referring to the Mbox interfaces (a different model to the one I am using though; different ID): http://mailman.alsa-project.org/pipermail/alsa-devel/2007-November/004394.h… http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg12273.html In the second one, which is from 2004, Clemens says: > Strange. But having two endpoints in one interface is not what the > driver was written for. I think part of the driver needs to be > rewritten before this device can work. Now this is a while ago, with a different interface. But the Mbox 2 mini also has two endpoints in one interface (see attached lsusb output), and I seem to be getting considerably more out of the interface than the original poster. So is it possible that the driver is now successfully getting audio to the playback endpoint only, and just needs some kind of mixer device control (or similar) for playback to work? Or is the 'success' with aplay/mplayer misleading -- how far off working is this? Thanks, -- Mark

1 0

[alsa-devel] [PATCH] snd-sbxfi: rename erroneous Master mixer control to "PCM Playback Volume".
by William Pitcock 19 Oct '08

19 Oct '08

The OSS4-provided master mixer control is actually relative to EMU20K1 port volume settings. So, it should be named PCM. The Master mixer control will be shortly readded as a control which sets the master volume. Signed-off-by: William Pitcock <nenolod(a)sacredspiral.co.uk> --- sound/pci/sbxfi/sbxfi.c | 28 ++++++++++++++-------------- 1 files changed, 14 insertions(+), 14 deletions(-) diff --git a/sound/pci/sbxfi/sbxfi.c b/sound/pci/sbxfi/sbxfi.c index c006278..3e99a97 100644 --- a/sound/pci/sbxfi/sbxfi.c +++ b/sound/pci/sbxfi/sbxfi.c @@ -155,7 +155,7 @@ struct sbxfi { int timer_reprogram; unsigned int base_rate; - int master_vol[2]; + int pcm_vol[2]; int capture_vol[2]; int capsrc; int micboost; @@ -1103,7 +1103,7 @@ static void sbxfi_setup_play_mixer(struct sbxfi *chip, int i, vol, audio_ch; for (i = 0; i < 2; i++) { - vol = port->vol[i] + chip->master_vol[i] - MAX_VOLUME; + vol = port->vol[i] + chip->pcm_vol[i] - MAX_VOLUME; if (vol < 0) vol = 0; vol = amop_vol_table[vol]; @@ -1124,9 +1124,9 @@ static int sbxfi_update_play_mixer(struct sbxfi *chip, int *vol) struct sbxfi_port *port; for (i = 0; i < 2; i++) { - if (vol[i] == chip->master_vol[i]) + if (vol[i] == chip->pcm_vol[i]) continue; - chip->master_vol[i] = vol[i]; + chip->pcm_vol[i] = vol[i]; spin_lock_irq(&chip->port_lock); list_for_each_entry(port, &chip->port_list, list) { if (port->substream->stream != @@ -1516,7 +1516,7 @@ static int __devinit sbxfi_create_pcm(struct sbxfi *chip) /* * Mixer interface */ -static int sbxfi_master_vol_info(struct snd_kcontrol *kcontrol, +static int sbxfi_pcm_vol_info(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_info *uinfo) { uinfo->type = SNDRV_CTL_ELEM_TYPE_INTEGER; @@ -1526,16 +1526,16 @@ static int sbxfi_master_vol_info(struct snd_kcontrol *kcontrol, return 0; } -static int sbxfi_master_vol_get(struct snd_kcontrol *kcontrol, +static int sbxfi_pcm_vol_get(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct sbxfi *chip = snd_kcontrol_chip(kcontrol); - ucontrol->value.integer.value[0] = chip->master_vol[0]; - ucontrol->value.integer.value[1] = chip->master_vol[1]; + ucontrol->value.integer.value[0] = chip->pcm_vol[0]; + ucontrol->value.integer.value[1] = chip->pcm_vol[1]; return 0; } -static int sbxfi_master_vol_put(struct snd_kcontrol *kcontrol, +static int sbxfi_pcm_vol_put(struct snd_kcontrol *kcontrol, struct snd_ctl_elem_value *ucontrol) { struct sbxfi *chip = snd_kcontrol_chip(kcontrol); @@ -1543,7 +1543,7 @@ static int sbxfi_master_vol_put(struct snd_kcontrol *kcontrol, vol[0] = ucontrol->value.integer.value[0]; vol[1] = ucontrol->value.integer.value[1]; - if (!memcmp(vol, chip->master_vol, sizeof(vol))) + if (!memcmp(vol, chip->pcm_vol, sizeof(vol))) return 0; if (vol[0] < 0) @@ -1658,13 +1658,13 @@ static int sbxfi_micboost_put(struct snd_kcontrol *kcontrol, static struct snd_kcontrol_new mixers[] __devinitdata = { { - .name = "Master Playback Volume", + .name = "PCM Playback Volume", .iface = SNDRV_CTL_ELEM_IFACE_MIXER, .access = (SNDRV_CTL_ELEM_ACCESS_READWRITE /* | SNDRV_CTL_ELEM_ACCESS_TLV_READ*/), - .info = sbxfi_master_vol_info, - .get = sbxfi_master_vol_get, - .put = sbxfi_master_vol_put, + .info = sbxfi_pcm_vol_info, + .get = sbxfi_pcm_vol_get, + .put = sbxfi_pcm_vol_put, /*.tlv = { .p = db_master_vol }*/ }, { -- 1.5.5.4

3 4

[alsa-devel] snd-xfi programming, some guidelines.
by James Courtier-Dutton 19 Oct '08

19 Oct '08

Hi, I have not had time to review the current work on the snd-xfi, but I have provided input if I think it would be useful. I have one more piece of information that might help. The xfi has two ways to talk to all the registers. 1) ioports using ioport pointer offset write method as familiar with older emu10k1 cards. 2) iomem using simple memory writes. The same registers on the xfi card can be accessed via both methods. There is some guidance as to when to use each. I.e. Do not use iomem for everything. There are some registers that take longer to write to than others. Unfortunately, the datasheet does not tell me which these slow are, so trial and error might be required. Now, if one uses the iomem to write to these registers that take a long time to update, it ties up the entire PCI bus for the entire duration, so this is not a good idea. So, the recommendation is that one should use ioports to access these slow registers as this will not block the PCI bus. I suggest putting a timer round each ioport and iomem write to find the slow ones. Kind Regards James

1 0