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

[alsa-devel] [PATCH v2] ALSA: snd-usb-audio: set the timeout for usb control set messages to 5000 ms
by Daniel Schürmann 20 Apr '13

20 Apr '13

Thank you Daniel for review. Here is an updated version of the patch against https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/ 581cbef46ae60073252208fc1f26dd1044f6e215 Set the timeout for USB control set messages according to the USB 2 spec §9.2.6.4 to 5000 ms. To avoid new issues, the get timeout is unchanged at 1000 ms, though it is 500 ms in the spec. This patch is required to run the Hercules RMX2 which needs a timeout > 1240 ms Signed-off-by: Daniel Schürmann <daschuer(a)mixxx.org> --- diff --git a/sound/usb/helper.c b/sound/usb/helper.c index c1db28f..c1caae4 100644 --- a/sound/usb/helper.c +++ b/sound/usb/helper.c @@ -23,6 +23,11 @@ #include "helper.h" #include "quirks.h" +/* Value from 9.2.6.4 USB 2 spec */ +#define USB_MSG_SET_TIMEOUT 5000 +/* Value from spec is 500 but we pick 1000 for legacy reasons */ +#define USB_MSG_GET_TIMEOUT 1000 + /* * combine bytes and get an integer value */ @@ -86,14 +91,19 @@ int snd_usb_ctl_msg(struct usb_device *dev, unsigned int pipe, __u8 request, { int err; void *buf = NULL; + int timeout; if (size > 0) { buf = kmemdup(data, size, GFP_KERNEL); if (!buf) return -ENOMEM; } + if (requesttype & USB_DIR_IN) + timeout = USB_MSG_GET_TIMEOUT; + else + timeout = USB_MSG_SET_TIMEOUT; err = usb_control_msg(dev, pipe, request, requesttype, - value, index, buf, size, 1000); + value, index, buf, size, timeout); if (size > 0) { memcpy(data, buf, size); kfree(buf);

3 4

[alsa-devel] DAPM widget power off
by yuvaraj r 20 Apr '13

20 Apr '13

Hi All, I have two different dais 1. Hifi Multimedia 2. Voice call dai Before opening voice call dai. I closed Hifi stream. After 5 sec Voice call stream dapm widget got powered off automatically. I am assuming that stream close event of Multimedia causing problem. What will issue in my cause. Thanks Yuvaraj

2 1

[alsa-devel] snd_pcm_avail() and snd_pcm_avail_update() always returns buffer_size
by Nate Case 20 Apr '13

20 Apr '13

Hello, I'm debugging an issue where both snd_pcm_avail_update() and snd_pcm_avail() are always returning buffer_size, even after successfully calling snd_pcm_writei() repeatedly. This is causing problems when I first start playback. My goal was to fill up the playback buffer until it's almost full when first starting, and then enter my regular playback loop where I write period_size at a time. However, I'm not able to tell when the playback buffer is full from snd_pcm_avail() or snd_pcm_avail_update() as expected. In case it's useful, the full snd_pcm_dump() output of the playback device is available here: http://pastebin.com/ai3e0cer To summarize the configuration, I'm using a chain of PCM devices that looks like this: Soft volume -> Rate conversion -> Route conversion -> HW PCM (USB audio) (notes: buffer_size for soft volume PCM is 640 [80ms], period size is 160 [20ms]. buffer_size for HW PCM is 3846 and period_size is 960. I'm opening the playback device in blocking mode, although the same thing appears to happen in non-blocking mode) Here is the sequence of events I'm seeing: 1) Call snd_pcm_writei() with 160 frames successfully. Function returns immediately in less than 1ms because the buffer is empty. 2) snd_pcm_avail() returns 640 (expected 640-160 = 480) snd_pcm_dump() shows the following for the HW PCM device: appl_ptr : 960 hw_ptr : 0 3) Call snd_pcm_writei() again with 160 frames successfully. Function returns immediately again. 4) snd_pcm_avail() returns 640 (expected 480-160 = 320) snd_pcm_dump() shows the following for the HW PCM device: appl_ptr : 1920 hw_ptr : 0 5) Cycle repeats two more times, with these values for apply_ptr/hw_ptr reported after each subsequent snd_pcm_writei() call: appl_ptr : 2880 hw_ptr : 288 appl_ptr : 3840 hw_ptr : 288 All along, snd_pcm_avail() returns 640. 6) Call snd_pcm_writei() with 160 frames again. This time, the buffer is actually full, so it blocks for 20 ms as expected. 7) snd_pcm_avail() returns 640 snd_pcm_dump() shows the following for the HW PCM device: appl_ptr : 4800 hw_ptr : 960 8) Continue this loop, with each subsequent snd_pcm_writei() call blocking for 20 ms, while snd_pcm_avail() always returns 640. Any ideas on why this could be happening? Or am I misunderstanding something here? Thanks, Nate Case <ncase(a)xes-inc.com>

2 2

Re: [alsa-devel] PCM buffering ussues ( or probably the lack of understanding )
by Lars-Peter Clausen 20 Apr '13

20 Apr '13

On 04/20/2013 12:59 PM, marcelg wrote: > Lars Peter, > > Thanks for your reply. > > Some things are more clear now, however one issue I still wonder. > > > Quote > > " >> Suppose I want to have some buffering inside my pcm driver, how will I be >> able to get some samples in advance before starting playback ? Can I just >> call pcm_period_elapsed() a few times in a row to get the buffer filled >> before starting the actual playcback, or does this cause side effects ? >> > Why'd you want to do that? > " > > > If Alsa is not having an internal buffer as you pointed out. An my driver > for example advertises > min periods = 1 and max_periods = 10. Then it means my drivers is capable > of buffering up to 10 periods. > > However what I notice is that the Alsa layer pcm_copy() always supplies > "period_bytes" after each call to period_elapsed() > > This would imply that even my driver is able to buffer 10 periods, it never > receives more data as one period, because I call period_elapsed() > as soon as the data is consumed. The ALSA core keeps track of how many bytes are available in your buffer. It will supply your driver with as many bytes as there is space in the buffer. So if you start playback you should see it supplying you more than one period worth of bytes. Once the buffer is full you'll naturally only get one new period of each period that has elapsed. But as I said before if you don't do anything other then copying data to your buffer in the copy callback, you should probably get rid of the copy callback altogether and let ALSA take care of writing the data to your buffer. This will also allow you to use for example mmap. - Lars

1 0

[alsa-devel] Invitation to connect on LinkedIn
by Barry Song via LinkedIn 20 Apr '13

20 Apr '13

LinkedIn ------------ Barry Song requested to add you as a connection on LinkedIn: ------------------------------------------ abdul, I'd like to add you to my professional network on LinkedIn. - Barry Accept invitation from Barry Song http://www.linkedin.com/e/jpxkk3-hfqntbbx-71/uii-rtptP1H4ViCg9YiBUOvto1r4_5… View profile of Barry Song http://www.linkedin.com/e/jpxkk3-hfqntbbx-71/rso/196461153/a2mu/name/138036… ------------------------------------------ You are receiving Invitation emails. This email was intended for abdul moiz. Learn why this is included: http://www.linkedin.com/e/jpxkk3-hfqntbbx-71/plh/http%3A%2F%2Fhelp%2Elinked… (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, USA.

1 0

[alsa-devel] PCM buffering ussues ( or probably the lack of understanding )
by marcelg 20 Apr '13

20 Apr '13

I am working on a PCM driver, have some issues and thing which are unclear to me, hopefully somebody here can clarify something for me. My PCM driver is straigh forward: - Copy callback copies the frames received in the callback into a small ringbuffer and starts a DMA transfer to the hardware. - DMA interrupt each times take the next chunk from the ringbuffer. - In the DMA interrupt the number of frames is counted, if te number >= period_size reported in runtime_struct pcm_period_elapsed() is called. - the pointer which is read by the pcm_pointer() callback is updated in each DMA interrupt. When using mplayer this works without problems, however with other applications like mpg123 its causes a lot of problems, for some reaosns I do not understand yet. It has something to do with buffer handling. basically in the cm driver I can influence a few parameters: periods_min/periods_max period_bytes_min, period_bytes_max buffer_size ( should be sufficient to hold periods_max with period_bytes_max I assume ) As far as I understand periods_min/periods_max is the size (number of buffer entries) of the internal ringbuffer Alsa uses. - Why is there both a min and a max ? How is chosen what will be used ? - Currently my period_min is set to 1 and my period_max set to 4, If I increase the period_max value it does not start properly, it seems that the samples are not deliverered in time. Is there any explanation for this, does the Alsa layer not any pre-buffering before the first copy() is called ? - Is there any advice / guidline for period min/max values ? I checked sourecs of severl drivers, some use 1 and some use values like 32 or more for period_max. The same applies to buffer_bytes min/max, currently my min is set to 128bytes , max to 2kB, larger values of max seem to cause more problems. From the documentation I understand that it does not matter if pcm_period_elapsed() is not always called, How dows the ALSA layer then know how many samples are played. the pointer value read the pcm_pointer() only counts from [0..period_max] so what if 2 or more calls to period_elapsed() are skipped ? Suppose I want to have some buffering inside my pcm driver, how will I be able to get some samples in advance before starting playback ? Can I just call pcm_period_elapsed() a few times in a row to get the buffer filled before starting the actual playcback, or does this cause side effects ? I noticed that the number of frames passed to pcm_copy is often less than the periods_size, is this determined by the application ? Lots of questions, but I try to understand the odd behaviour with certain applications ( and the best settings for a pcm driver which will work with most applications ) Any help would be appreciated. Marcel

3 2

Re: [alsa-devel] [PATCH 4/7] ALSA: compress_core: Add support for capture streams
by Vinod Koul 20 Apr '13

20 Apr '13

On Thu, Apr 18, 2013 at 11:02:08AM +0100, Charles Keepax wrote: > Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> > Signed-off-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> > --- > sound/core/compress_offload.c | 43 +++++++++++++++++++++++++++++++++++++++- > 1 files changed, 41 insertions(+), 2 deletions(-) > > diff --git a/sound/core/compress_offload.c b/sound/core/compress_offload.c > index 52ca4cc..52a2765 100644 > --- a/sound/core/compress_offload.c > +++ b/sound/core/compress_offload.c > @@ -296,7 +296,41 @@ static ssize_t snd_compr_write(struct file *f, const char __user *buf, > static ssize_t snd_compr_read(struct file *f, char __user *buf, > size_t count, loff_t *offset) > { > - return -ENXIO; > + struct snd_compr_file *data = f->private_data; > + struct snd_compr_stream *stream; > + size_t avail; > + int retval; > + > + if (snd_BUG_ON(!data)) > + return -EFAULT; > + > + stream = &data->stream; > + mutex_lock(&stream->device->lock); > + > + /* read is allowed when stream is running */ > + if (stream->runtime->state != SNDRV_PCM_STATE_RUNNING) { > + retval = -EBADFD; > + goto out; minor one but shouldnt we allow read even when we have stoped or paused the stream. Stop is important as you might want to get all buffers after you have stopped. > + } > + > + avail = snd_compr_get_avail(stream); > + pr_debug("avail returned %ld\n", (unsigned long)avail); > + /* calculate how much we can read from buffer */ > + if (avail > count) > + avail = count; > + > + if (stream->ops->copy) { > + retval = stream->ops->copy(stream, buf, avail); > + } else { > + retval = -ENXIO; > + goto out; > + } > + if (retval > 0) > + stream->runtime->total_bytes_transferred += retval; > + > +out: > + mutex_unlock(&stream->device->lock); > + return retval; > } > > static int snd_compr_mmap(struct file *f, struct vm_area_struct *vma) > @@ -481,9 +515,14 @@ snd_compr_set_params(struct snd_compr_stream *stream, unsigned long arg) > retval = stream->ops->set_params(stream, params); > if (retval) > goto out; > - stream->runtime->state = SNDRV_PCM_STATE_SETUP; > + > stream->metadata_set = false; > stream->next_track = false; > + > + if (stream->direction == SND_COMPRESS_PLAYBACK) > + stream->runtime->state = SNDRV_PCM_STATE_SETUP; > + else > + stream->runtime->state = SNDRV_PCM_STATE_PREPARED; > } else { > return -EPERM; > } > -- > 1.7.2.5 >

3 2

[alsa-devel] Solved Hercules RMX2
by Daniel Schürmann 20 Apr '13

20 Apr '13

Hallo Alsa Developers, I have fixed Support for Hercules RMX2. You can find the Bug and the patch here: https://bugs.launchpad.net/mixxx/+bug/1096687 The issue was caused by the first time setting the rate. I have changed the usb_msg_timeout to 1500 ms to make it work. The measures time is a ~1240 ms. All following rate settings are finished in not time < 4 ms Sound is now working fine but there are still IO errors just after connecting the device errno 5 - input/output error Here the extended Log: Apr 14 23:50:37 KellerPc kernel: [19213.746929] snd_usb_autoresume() -19 ID:6f8b113 chip->shutdown 0 chip->probing 1. Apr 14 23:50:37 KellerPc kernel: [19213.746934] -5 1 cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0x0, type = 4 Apr 14 23:50:37 KellerPc kernel: [19213.747053] snd_usb_autoresume() -19 ID:6f8b113 chip->shutdown 0 chip->probing 1. Apr 14 23:50:37 KellerPc kernel: [19213.747058] -5 1 cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0x0, type = 4 Apr 14 23:50:37 KellerPc kernel: [19213.747430] snd_usb_autoresume() -19 ID:6f8b113 chip->shutdown 0 chip->probing 1. Apr 14 23:50:37 KellerPc kernel: [19213.747435] -5 1 cannot get ctl value: req = 0x83, wValue = 0x201, wIndex = 0x0, type = 4 Apr 14 23:50:37 KellerPc kernel: [19213.747554] snd_usb_autoresume() -19 ID:6f8b113 chip->shutdown 0 chip->probing 1. Apr 14 23:50:37 KellerPc kernel: [19213.747559] -5 1 cannot get ctl value: req = 0x83, wValue = 0x200, wIndex = 0x0, type = 4 Apr 14 23:50:37 KellerPc kernel: [19213.752599] usbcore: registered new interface driver snd-usb-audio Apr 14 23:50:37 KellerPc kernel: [19213.775204] snd_usb_ctl_msg() dev:ed5eb000 pipe:80000d80 request:02, requesttype:a1, value:0201, index:0a00, data_size:8. Apr 14 23:50:37 KellerPc kernel: [19213.776264] snd_usb_ctl_msg() dev:ed5eb000 pipe:80000d80 request:02, requesttype:a1, value:0201, index:0a00, data_size:8. Apr 14 23:50:37 KellerPc kernel: [19213.776436] snd_usb_ctl_msg() dev:ed5eb000 pipe:80000d80 request:02, requesttype:a1, value:0201, index:0a00, data_size:8. The current solution is fine for me, but maybe there is an other place for tweaking the startup timing. Any ideas? Is it possible to include the fix in trunk? Thank you. Kind regards, Daniel Schürmann

3 9

[alsa-devel] [PATCH 2/2] ALSA: ASoC: spdif_receiver: Add DT support
by Michal Bachraty 19 Apr '13

19 Apr '13

Add devicetree support for this dummy audio soc driver. Signed-off-by: Michal Bachraty <michal.bachraty(a)streamunlimited.com> --- sound/soc/codecs/spdif_receiver.c | 12 ++++++++++++ 1 file changed, 12 insertions(+) diff --git a/sound/soc/codecs/spdif_receiver.c b/sound/soc/codecs/spdif_receiver.c index dd8d856..5d469c7 100644 --- a/sound/soc/codecs/spdif_receiver.c +++ b/sound/soc/codecs/spdif_receiver.c @@ -21,6 +21,9 @@ #include <sound/soc.h> #include <sound/pcm.h> #include <sound/initval.h> +#include <linux/of.h> + +#define DRV_NAME "spdif-dir" #define STUB_RATES SNDRV_PCM_RATE_8000_192000 #define STUB_FORMATS (SNDRV_PCM_FMTBIT_S16_LE | \ @@ -51,12 +54,21 @@ static int spdif_dir_remove(struct platform_device *pdev) return 0; } +#ifdef CONFIG_OF +static const struct of_device_id spdif_dit_dt_ids[] = { + { .compatible = DRV_NAME, }, + { } +}; +MODULE_DEVICE_TABLE(of, spdif_dits_dt_ids); +#endif + static struct platform_driver spdif_dir_driver = { .probe = spdif_dir_probe, .remove = spdif_dir_remove, .driver = { .name = "spdif-dir", .owner = THIS_MODULE, + .of_match_table = of_match_ptr(spdif_dit_dt_ids), }, }; -- 1.7.9.5

1 0

Re: [alsa-devel] [PATCH 5/7] ASoC: soc-compress: Deduce stream direction
by Vinod Koul 19 Apr '13

19 Apr '13

On Thu, Apr 18, 2013 at 11:02:38AM +0100, Charles Keepax wrote: > Previously we just hard coded all streams as playback streams, this > patch checks the DAI to see if it is a capture or playback stream. It is > worth noting that at this time only unidirectional streams are > supported. well the intention was the compress device would be either playback or record. you should have two devices if you support both. > > Signed-off-by: Charles Keepax <ckeepax(a)opensource.wolfsonmicro.com> > Signed-off-by: Richard Fitzgerald <rf(a)opensource.wolfsonmicro.com> > --- > sound/soc/soc-compress.c | 9 ++++++++- > 1 files changed, 8 insertions(+), 1 deletions(-) > > diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c > index da83e56..3853f7e 100644 > --- a/sound/soc/soc-compress.c > +++ b/sound/soc/soc-compress.c > @@ -384,7 +384,14 @@ int soc_new_compress(struct snd_soc_pcm_runtime *rtd, int num) > /* check client and interface hw capabilities */ > snprintf(new_name, sizeof(new_name), "%s %s-%d", > rtd->dai_link->stream_name, codec_dai->name, num); > - direction = SND_COMPRESS_PLAYBACK; > + > + if (codec_dai->driver->playback.channels_min) > + direction = SND_COMPRESS_PLAYBACK; > + else if (codec_dai->driver->capture.channels_min) > + direction = SND_COMPRESS_CAPTURE; > + else > + return -EINVAL; > + > compr = kzalloc(sizeof(*compr), GFP_KERNEL); > if (compr == NULL) { > snd_printk(KERN_ERR "Cannot allocate compr\n"); > -- > 1.7.2.5 >

1 0