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

[PATCH] ALSA: usb-audio: parse UAC2 sample rate ranges correctly
by Daniel Mack 11 Jun '10

11 Jun '10

A device may report its supported sample rates in ranges rather than in discrete triplets. The code used to only parse the MIN field instead of properly paying attention to the MAX and RES values. Also, handle RES values of 1 correctly and announce a continous sample rate range in this case. Signed-off-by: Daniel Mack <daniel(a)caiaq.de> Reported-by: Alex Lee <alexlee188(a)gmail.com> --- sound/usb/format.c | 92 +++++++++++++++++++++++++++++++++++++++++---------- 1 files changed, 74 insertions(+), 18 deletions(-) diff --git a/sound/usb/format.c b/sound/usb/format.c index 8eccf17..30364ab 100644 --- a/sound/usb/format.c +++ b/sound/usb/format.c @@ -206,6 +206,60 @@ static int parse_audio_format_rates_v1(struct snd_usb_audio *chip, struct audiof } /* + * Helper function to walk the array of sample rate triplets reported by + * the device. The problem is that we need to parse whole array first to + * get to know how many sample rates we have to expect. + * Then fp->rate_table can be allocated and filled. + */ +static int parse_uac2_sample_rate_range(struct audioformat *fp, int nr_triplets, + const unsigned char *data) +{ + int i, nr_rates = 0; + + fp->rates = fp->rate_min = fp->rate_max = 0; + + for (i = 0; i < nr_triplets; i++) { + int min = combine_quad(&data[2 + 12 * i]); + int max = combine_quad(&data[6 + 12 * i]); + int res = combine_quad(&data[10 + 12 * i]); + int rate; + + if ((max < 0) || (min < 0) || (res < 0) || (max < min)) + continue; + + /* + * for ranges with res == 1, we announce a continuous sample + * rate range, and this function should return 0 for no further + * parsing. + */ + if (res == 1) { + fp->rate_min = min; + fp->rate_max = max; + fp->rates = SNDRV_PCM_RATE_CONTINUOUS; + return 0; + } + + for (rate = min; rate <= max; rate += res) { + if (fp->rate_table) + fp->rate_table[nr_rates] = rate; + if (!fp->rate_min || rate < fp->rate_min) + fp->rate_min = rate; + if (!fp->rate_max || rate > fp->rate_max) + fp->rate_max = rate; + fp->rates |= snd_pcm_rate_to_rate_bit(rate); + + nr_rates++; + + /* avoid endless loop */ + if (res == 0) + break; + } + } + + return nr_rates; +} + +/* * parse the format descriptor and stores the possible sample rates * on the audioformat table (audio class v2). */ @@ -215,7 +269,7 @@ static int parse_audio_format_rates_v2(struct snd_usb_audio *chip, { struct usb_device *dev = chip->dev; unsigned char tmp[2], *data; - int i, nr_rates, data_size, ret = 0; + int nr_triplets, data_size, ret = 0; int clock = snd_usb_clock_find_source(chip, chip->ctrl_intf, fp->clock); if (clock < 0) { @@ -237,8 +291,8 @@ static int parse_audio_format_rates_v2(struct snd_usb_audio *chip, goto err; } - nr_rates = (tmp[1] << 8) | tmp[0]; - data_size = 2 + 12 * nr_rates; + nr_triplets = (tmp[1] << 8) | tmp[0]; + data_size = 2 + 12 * nr_triplets; data = kzalloc(data_size, GFP_KERNEL); if (!data) { ret = -ENOMEM; @@ -259,26 +313,28 @@ static int parse_audio_format_rates_v2(struct snd_usb_audio *chip, goto err_free; } - fp->rate_table = kmalloc(sizeof(int) * nr_rates, GFP_KERNEL); + /* Call the triplet parser, and make sure fp->rate_table is NULL. + * We just use the return value to know how many sample rates we + * will have to deal with. */ + kfree(fp->rate_table); + fp->rate_table = NULL; + fp->nr_rates = parse_uac2_sample_rate_range(fp, nr_triplets, data); + + if (fp->nr_rates == 0) { + /* SNDRV_PCM_RATE_CONTINUOUS */ + ret = 0; + goto err_free; + } + + fp->rate_table = kmalloc(sizeof(int) * fp->nr_rates, GFP_KERNEL); if (!fp->rate_table) { ret = -ENOMEM; goto err_free; } - fp->nr_rates = 0; - fp->rate_min = fp->rate_max = 0; - - for (i = 0; i < nr_rates; i++) { - int rate = combine_quad(&data[2 + 12 * i]); - - fp->rate_table[fp->nr_rates] = rate; - if (!fp->rate_min || rate < fp->rate_min) - fp->rate_min = rate; - if (!fp->rate_max || rate > fp->rate_max) - fp->rate_max = rate; - fp->rates |= snd_pcm_rate_to_rate_bit(rate); - fp->nr_rates++; - } + /* Call the triplet parser again, but this time, fp->rate_table is + * allocated, so the rates will be stored */ + parse_uac2_sample_rate_range(fp, nr_triplets, data); err_free: kfree(data); -- 1.7.1

1 0

Re: [alsa-devel] [sdr-widget] UAC2 sampling freq setting
by Daniel Mack 11 Jun '10

11 Jun '10

(Moving this discussion from sdr-widget to alsa-devel. Can't Cc: the original mailing list as it forbids cross-posting) On Thu, Jun 10, 2010 at 09:36:48PM -0700, Alex Lee wrote: > I studied the driver source again and it becomes apparent that the > driver only looks at the MIN value of the triplet (MIN, MAX, RES). It > does not take into consideration of the MAX and the RES in each > triplet. For samplerates it does that, yes. > The driver calculates its own MIN and MAX values by going through all > the triplets in the clock source. In the present firmware, we only > have ONE triplet in each clock source, with: > > # of triplets = 1 (2 byte value) > MIN 48000 > MAX 96000 > RES 48000 Ah, that's a corner case I didn't see. I'll fix this. > in accordance with the UAC2 specs. The present driver code expects: > > # of triplets = 2 (2 byte value) > triplet 1: > > MIN 48000 MAX 48000 RES 00000 > > triplet 2: > > MIN 96000 MAX 96000 RES 00000 Yes, that's right. All firmware code I've seen so far also has a triplet for each discrete sample rate. > Thus the present driver cannot decode the 1st case above correctly, > and only get the 48khz value. > > I will update the firmware to cater to the 2nd case above and we > should have the 96khz back :-) Ok, fair fix. I'll make sure future versions of the driver also support the other approach. Thanks, Daniel

1 0

[alsa-devel] HDMI audio with NVIDIA NVS 3100M
by Jakub Schmidtke 11 Jun '10

11 Jun '10

Hi. I am having problems getting the HDMI audio working with NVIDIA NVS 3100M card (this is a card in Lenovo T410 laptop). When I'm not using any options for the snd-hda-intel module, I have 4 controls in alsamixer: S/PDIF >S/PDIF 1 S/PDIF 2 S/PDIF 3. Playing to any of the 4 available devices doesn't produce any sound through TV. In a thread about GT2XX cards ( http://forum.xbmc.org/showthread.php?p=527386 ) there was a solution - adding "options snd-hda-intel enable_msi=0 probe_mask=0xffff,0xfff2" to modprobe's config. When I am using this option I have only one S/PDIF output, but I am still not getting any sound through TV. I have run alsa-info.sh script and uploaded the results (this is without any options for the modprobe): http://www.alsa-project.org/db/?f=7514a673a73aca75d58c3e426c59d0bf6ca3dfc8 This is info from lspci about this card: 01:00.0 VGA compatible controller: nVidia Corporation NVIDIA NVS 3100M (rev a2) 01:00.0 0300: 10de:0a6c (rev a2) 01:00.1 Audio device: nVidia Corporation High Definition Audio Controller (rev a1) 01:00.1 0403: 10de:0be3 (rev a1) Any hints? Maybe I can debug or check something else? I am ok with modifying and building kernel modules, I just have no idea where to start... Thanks!

1 0

[alsa-devel] Speaker auto-mute doesn't work on ALC269
by David Song 10 Jun '10

10 Jun '10

When a headphone is plugged, I can hear sound from both speaker and headphone. This issue exists on ASUS EeePC S101 and EeePC 1005PE which both have ALC269. I'm testing with the latest kernel. Any regression here?

2 1

Re: [alsa-devel] [PATCH] NUC900: patch for fix build error
by Liam Girdwood 10 Jun '10

10 Jun '10

On Thu, 2010-06-10 at 10:40 +0800, Wan ZongShun wrote: > This patch is to change 'auido.h' to 'audio.h' for > fixing nuc900 alsa driver build error. > > > Signed-off-by: Wan ZongShun <mcuos.com(a)gmail.com> Acked-by: Liam Girdwood <lrg(a)slimlogic.co.uk> -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk

2 1

[alsa-devel] New release of amidicat program, connecting MIDI to stdin/out
by Josh Lehan 10 Jun '10

10 Jun '10

Hello. On the mailing list a few months ago, mentioned a program I had written, then called "midicat". Found out there's another product by that name. So, the new name of the program is "amidicat". The "a" prefix also clarifies that it's an ALSA program. It's a program that connects the ALSA MIDI sequencer to standard input and output. Among other things, this is fun for prototyping quick MIDI one-liners on the command line, such as "echo 903C7F | amidicat" to play Middle C. I have made a new release of the program, which is basically unchanged, except for a few bug fixes (thanks to Valgrind for discovering a minor memory leak). The biggest improvement is that there's now a manual page and a DocBook documentation page. Here's the webpage for amidicat, if interested: http://www.krellan.com/amidicat/ The download is there. Have fun, and thanks for reading this. Josh Lehan

2 2

[alsa-devel] [PATCH v3 0/5] OMAP/ASoC: McBSP: FIFO handling related fixes
by Peter Ujfalusi 10 Jun '10

10 Jun '10

Hello, Changes since RFC v2: - Comments added explaining the changes, and documenting the API in patch2 - In patch5: - Variable names changed in the hw_rule function - hw_rule function got renamed - The snd_pcm_hw_rule_add calls moved so it anly got set on OMAP3 Intro mail from the previous series: This series aims to correct how the McBSP FIFO is viewed, and handled. Introduction of the problem: OMAP McBSP FIFO is word structured: McBSP2 has 1024 + 256 = 1280 word long buffer, McBSP1,3,4,5 has 128 word long buffer This means, that the size of the FIFO depends on the McBSP word size configuration. For example on McBSP3: 16bit samples: size is 128 * 2 = 256 bytes 32bit samples: size is 128 * 4 = 512 bytes It is simpler to place constraint for buffer and period based on channels. McBSP3 as example again (16 or 32 bit samples): 1 channel (mono): size is 128 frames (128 words) 2 channels (stereo): size is 128 / 2 = 64 frames (2 * 64 words) 4 channels: size is 128 / 4 = 32 frames (4 * 32 words) Since now the McBSP codec supports not only 16bit samples (32biut has been recently added), the FIFO size handling is no longer correct, since it has been hard wired for 16bit word length. The series changes how the users of McBSP are configuring the FIFO: It used to be 0 based (0 meant 1 word threshold). After this series users can configure the threshold in 1 base mode (1 means 1 word threshold). The platform code now provides the _full_ size of the FIFO in words, instead of the already limited value used in the past. In ASoC omap-mcbsp code hw_rule based constraint refinement is going to be used instead of the hardwired static constraint, which was correct only in case of 16bit word length. The hw_rule is refining the minimum buffer size based on the channel number going to be used by the coming stream. In case of threshold mode additional hw_rule refines the maximum allowed period size. The series are generated agains Takashi's sound-2.6: topic/asoc branch. CCing also Eduardo, and Eero since they have worked on the original FIFO/threshold implementation. All commetns and testers are welcome! Peter --- Peter Ujfalusi (5): OMAP: McBSP: Function to query the FIFO size OMAP2: McBSP: Change the way how the FIFO is handled OMAP2: McBSP: Use the port's buffer_size when calculating tx delay ASoC: omap-mcbsp: Save, and use wlen for threshold configuration ASoC: omap-mcbsp: Place correct constraints for streams arch/arm/mach-omap2/mcbsp.c | 10 ++-- arch/arm/plat-omap/include/plat/mcbsp.h | 2 + arch/arm/plat-omap/mcbsp.c | 51 ++++++++++----- sound/soc/omap/omap-mcbsp.c | 113 ++++++++++++++++++++++++------- 4 files changed, 129 insertions(+), 47 deletions(-)

5 12

[alsa-devel] External samplerate changes, UAC2 clock topologies
by Daniel Mack 10 Jun '10

10 Jun '10

Hi, when I implemented the basics for parsing the UAC2 clock functions, I came across some principal questions I would like to discuss. As I wrote in the commit log, UAC2 supports a number of clock units which can be combined to complex topologies. The single unit types are - clock sources (can be fixed, variable, programmable and synced to the USB clock) - clock switches, which let the host decide which one out of many input pins appears on its output pin - clock multipliers, which have a numerator and a denominator, and both can be read-only or read-write, respectively A clock source has controls for its frequency and its validity, a clock selector has a control to control its current state, and a clock multiplier has controls for its numerator and denominator The driver is currently able to walk the graph of connected units in order to find CLOCK_SOURCE descriptors as end-leafs. This is mandatory as all requests for sample rate queries have to be sent to this unit type. This raises the first question, as the driver can only know which sample rates are supported in the currently selected combination of selectors. Once the user changes any of them (which is currently already possible as clock selectors are exported as mixer controls), everything can change. And this can even happen while the stream is active, because there's currently no check about whether the clock selector is part of the actively used path. The second issue I see is that a clock can lose its validity. A real-life example is an external S/PDIF connected device which provides a clock and which is suddenly disconnected. Firmwares are expected to notify the host about such cases, and these messages are trivial to dispatch. However, I wonder how the driver should react on this. From a user's perspective, it would be best to just make the driver find another clock path which reports a valid clock source endpoint, changes the sample rate accordingly and continues streaming. There would be a gap in the stream of course, but at least it would not kill the applications or require major exception handling in userspace. I wonder which approaches are actually possible to implement, which details in the ALSA core would need to be extended, and so on. Any oppinions? Has this been done before for any other audio hardware supported by ALSA? Thanks, Daniel

5 6

[alsa-devel] Mixer volume/decibel mapping
by Sebastian H. 10 Jun '10

10 Jun '10

Hello everyone I'm working on an ALSA-Mixer application for C++/Qt4 and stumbled over volume and decibel mapping for sliders. My question: Is there always an 1 to 1 mapping from volume to decibel and vice versa or can there be decibel values in between two volume steps? Regards, Sebastian H.

7 38

[alsa-devel] snd_mixer handle in two threads
by Sebastian H. 09 Jun '10

09 Jun '10

Hello again This is still about the alsamixer-qt4 application I working on. This time I wonder if a snd_mixer_t handle created with snd_mixer_open ( ... ) can be used in two threads concurrently. One thread should be the main Qt4 GUI thread and the second thread should only poll ( ... ) blocking for ALSA events on the shared snd_mixer_t handle in accompany with snd_mixer_poll_descriptors_count ( ... ) snd_mixer_poll_descriptors ( ... ) snd_mixer_poll_descriptors_revents ( ... ) The second thread then will post Qt4 signals to the main thread on occassion. Does this sound feasible? This approach seems neccessary as I want to avoid timed polls and any integration of linux poll() in the Qt4 mail loop seems to boil down to timed polls. Regards, Sebastian H.

1 1