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

Re: [alsa-devel] USB Audio questions
by Daniel Mack 15 Aug '11

15 Aug '11

Hi, On Mon, Aug 15, 2011 at 10:31 PM, Pierre-Louis Bossart <pierre-louis.bossart(a)linux.intel.com> wrote: > I am trying to prototype an application where the key requirement is > playback with minimal power on USB audio accessories while maintaining tight > synchronization with video. With the default ALSA USB code, I am getting > ~130 interrupts/s due to audio, a fairly high CPU load and a very poor sync, > exactly the opposite of my goals... > After a careful analysis of the code I found a couple of issues where the > help of experts would be welcome: > > - Is there any good reason why the max number of packets per urb defaults to > 8? This end-ups being the root cause for the large number of interrupts. My > headset supports up to 192 bytes/packet, that means 1536 bytes/urb and 125 > interrupts/s. Using more packets/urb results in a linear decrease of the > interrupt rate. You cannot use more than 8 subframes per ISO urb, that's what how USB is designed. What exactly did you do in you test? Did you increase MAX_URBS? > - Increasing the number of packets/urbs solves my power issue but not the > synchronization issue. If I reduce the number of urbs to reduce the > interrupt rate, then the accuracy of the hw_pointer is decreased big time > and it becomes difficult to synchronize with video. The .pointer routine > only keeps track of retired urbs, it seems there's no way to know how many > samples were played at a given time? It also makes pulseaudio behave > somewhat strangely since the driver only provides an approximate position. > In the CAIQ driver code, the .pointer routine seems to rely on a direct > register read, a more efficient way to do things. Isn't there a direct way > to query the usb core to know how many bytes have been transmitted and make > the hw_ptr/delay information independent of the urb buffer size? Just to be sure - you're talking about the driver in sound/usb/caiaq, right? After a short comparison, I'd say both the caiaq driver and the generic driver do more or less the same in regard to the .pointer value, as for the output stream, they both increase their internal counter when the packet is prepared, shortly before it is submitted to the host controller. Increasing the number of URBs. Admittedly, this approach is questionable, as a larger number of prepared output buffers will actually cause the client believe that more data has already been written already. You could try moving the hwptr_done increase statement into the retire callback (which is the first place we get to know about packets that have been sent to the device)? > - Is there any reason why the driver relies on vmalloc and memcpy? It seems > like using physically-contiguous memory would be more efficient, as done in > the CAIQ driver? I hacked something to use prealloc_pages/malloc_pages and > things seem to work fine. Can you show a patch? Daniel

2 1

Re: [alsa-devel] hda-intel and runtime power-management
by Tatulea, Dragos 15 Aug '11

15 Aug '11

On Mon, Aug 8, 2011 at 9:11 AM, Takashi Iwai <tiwai(a)suse.de> wrote: > At Sun, 7 Aug 2011 20:55:52 +0300, > Tatulea, Dragos wrote: > > > >> >> I'm in the process of enabling pm runtime pm for the hda_intel > driver, > > >> >> not being sure if this is a sane task :). Noticed that > > >> >> CONFIG_SND_HDA_POWER_SAVE disables codecs and chip when they are > not > > >> >> in use, but the power gain is not noticeable on my hw. On the other > > >> >> hand, a full suspend (azx_suspend) does save a few hundred mW's. > > >> >> I am aware that this is hw specific, but I would like to take > > >> >> advantage of the full suspend. Suspend/resume latency is below > jiffy > > >> >> resolution. > > >> > > > >> > Hm, it's strange. Basically the current power-save does almost > > >> > equivalent with the normal suspend/resume, i.e. the codec is > > >> > suspended and azx_stop_chip() is called. Make sure that the > > >> > power-saving is really kicked in during your test. > > >> > > > >> Indeed, I checked and a codec is stuck in a power transition for some > reason. > > > > > > You should check who accessing the device files via fuser, etc. > > > > Yes, there's a non-muted pcm around there that prevents the codec from sleeping. I have a patch that checks for all substream states and puts the chip to sleep when they are all paused/suspended. Is this a bad idea? It could be that resuming the chip takes too long, depending on hw... > > >> Besides that, it would be nicer to have the currently standard runtime > > >> pm on codec bus instead of doing the same thing with > > >> CONFIG_SND_HDA_POWER_SAVE, right? > > > > > > Ideally, yes, but practically it's difficult, so far, because the > > > driver can manage multiple codecs and we need the individual codec > > > power-up/down. With the current runtime pm scheme, it's difficult to > > > implement like this, as it's no simple suspend/resume of the driver > > > itself. > > > > > The codec bus can contain the generic runtime pm part which will call > > runtime_suspend/_resume for individual codecs, depending on usage. > > Each codec can register it's own dev_pm_ops. > > Yes, but this would need relatively big changes in the structure > of the hd-audio driver, e.g. assigning struct device per codec > instance, etc. > > Still looking into it, maybe there's a less invasive way of doing this. Thanks, Dragos

3 3

Re: [alsa-devel] HDAudio period/buffer sizes
by Takashi Iwai 15 Aug '11

15 Aug '11

At Tue, 26 Jul 2011 14:23:40 -0500, Pierre-Louis Bossart wrote: > > that the buffer itself was already aligned to 128 bytes from the > > very beginning as it's allocated via dma_alloc_coherent(). > > The fact that the commit fixes the real problem means that the buffer > > size must be aligned, too, at least for some hardware. > > I checked internally and the reply was "There is no requirement the buffer > must be 128 byte multiples. As long as it is integer number of samples, we > are good." > > What's the best way to deal with it? Add a driver option? A compilation > option? I'd say a driver option since this must be dynamically adjustable. Care to make a patch? For 3.2 (after 3.1 merge window), we can disable 128-bytes limit as default again for testing. If someone hits the problem, he can switch easily and we can investigate more at this time. thanks, Takashi

3 3

Re: [alsa-devel] [PATCH] ASoC: sta32x: shortcut the for loop to get ir and mcs
by Mark Brown 15 Aug '11

15 Aug '11

On Sun, Aug 14, 2011 at 11:31:04AM +0800, Axel Lin wrote: > There is exactly one match or no match at all during the for loop iteration, > thus we can break from the for loop once a match is found. > > Signed-off-by: Axel Lin <axel.lin(a)gmail.com> Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] ASoC: nuc900-pcm: remove unused variable 'dai'
by Mark Brown 15 Aug '11

15 Aug '11

On Mon, Aug 15, 2011 at 04:38:34PM +0800, Axel Lin wrote: > Remove unused variable 'dai' to eliminate below warning. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] ASoC: soc-pcm: Remove unused global mutex
by Mark Brown 15 Aug '11

15 Aug '11

On Sun, Aug 14, 2011 at 08:00:12AM +0800, Axel Lin wrote: > Since commit b8c0dab9bf3373010e857a8d3f1b594c60a348dd > "ASoC: core - PCM mutex per rtd", > the global pcm_mutex is not being used any more. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] ASoC: soc-cache: Remove unneeded codec_drv pointer variable in snd_soc_lzo_get_blksize
by Mark Brown 15 Aug '11

15 Aug '11

On Sat, Aug 13, 2011 at 09:27:16PM +0800, Axel Lin wrote: > Since commit aea170a099793abcd0e6de46b947458073204241 > "ASoC: soc-cache: Add reg_size as a member to snd_soc_codec", > the codec_drv pointer variable is not used in snd_soc_lzo_get_blksize. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] ASoC: soc-cache: Remove unneeded codec_drv pointer variable in snd_soc_flat_cache_init
by Mark Brown 15 Aug '11

15 Aug '11

On Sat, Aug 13, 2011 at 09:12:01PM +0800, Axel Lin wrote: > Since commit d779fce5d79525d66269c8f6e430e1515d697f3d > "ASoC: soc-cache: Ensure flat compression uses a copy of the defaults cache", > the codec_drv pointer variable is not used any more. Applied, thanks.

1 0

Re: [alsa-devel] [PATCH] ASoC: s6000-pcm: remove unused variable 'dai'
by Mark Brown 15 Aug '11

15 Aug '11

On Sat, Aug 13, 2011 at 11:32:56AM +0800, Axel Lin wrote: > Signed-off-by: Axel Lin <axel.lin(a)gmail.com> Applied, thanks.

1 0

[alsa-devel] [PATCH v2 1/5] ASoC: ad193x: fix registers definition
by Scott Jiang 15 Aug '11

15 Aug '11

fix dac word len mask and adc tdm fmt shift value Signed-off-by: Scott Jiang <scott.jiang.linux(a)gmail.com> --- sound/soc/codecs/ad193x.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/codecs/ad193x.h b/sound/soc/codecs/ad193x.h index 9747b54..c1029d2 100644 --- a/sound/soc/codecs/ad193x.h +++ b/sound/soc/codecs/ad193x.h @@ -34,7 +34,7 @@ #define AD193X_DAC_LEFT_HIGH (1 << 3) #define AD193X_DAC_BCLK_INV (1 << 7) #define AD193X_DAC_CTRL2 0x804 -#define AD193X_DAC_WORD_LEN_MASK 0xC +#define AD193X_DAC_WORD_LEN_MASK 0x18 #define AD193X_DAC_MASTER_MUTE 1 #define AD193X_DAC_CHNL_MUTE 0x805 #define AD193X_DACL1_MUTE 0 @@ -63,7 +63,7 @@ #define AD193X_ADC_CTRL1 0x80f #define AD193X_ADC_SERFMT_MASK 0x60 #define AD193X_ADC_SERFMT_STEREO (0 << 5) -#define AD193X_ADC_SERFMT_TDM (1 << 2) +#define AD193X_ADC_SERFMT_TDM (1 << 5) #define AD193X_ADC_SERFMT_AUX (2 << 5) #define AD193X_ADC_WORD_LEN_MASK 0x3 #define AD193X_ADC_CTRL2 0x810 -- 1.7.0.4

4 13