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

[alsa-devel] Support for DSD streams (was: Re: [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work)
by Daniel Mack 23 Mar '13

23 Mar '13

Hi Andreas, On 22.03.2013 17:05, Andreas Koch wrote: > At 01:11 AM 3/22/2013, Daniel Mack wrote: >> Hi Jussi, >> Hi Andreas, >> >> On 21.03.2013 22:21, Jussi Laako wrote: >>> On 03/18/2013 03:49 PM, Daniel Mack wrote: >>>> Yes. If at all, we should add a SND_PCM_FORMAT_DSD, and a quirk for that >>>> device. But given that there is no application for DSD in userspace >>>> either, we probably don't need to care. >>> >>> Yes there is? At least my application. And I'd be happy to support any >>> custom format created for the purpose... :) >> >> Ah, interesting. So what *are* you using right now for your transport in >> userspace? Is your application abusing standard PCM interfaces that are >> 'known' to be in fact DSD? How do other DACs expose their interfaces in >> the Linux world, and which ones did you test your application with? >> >> If there's actual need for a new SND_PCM_FORMAT, it would be easy to >> patch it through all the layers down to userspace. >> >>> I would propose to create custom 8-bit sample formats for DSD purposes, >>> similar to the ASIO formats. Practically two main ones, byte with oldest >>> bit in MSB and byte with oldest bit in LSB. And maybe the "DSD-wide" one >>> which is 8-bit DSD sample. >> >> Andreas, which modes does the MPD-3 accept exactly on its two 'raw data' >> interfaces? The only hint I have is that one of it is 8-bit and the >> other is 16-bit, but given the lack of a proper test setup for this >> format, I can't currently test anything. > > The 8-bit raw format is for 2.8MHz DSD and the 16-bit format is for > 5.6MHz DSD. In both cases the driver sets the sample rate to 352.8kHz > on the DAC, but then sends either 8 bits or 16 bits depending on the > DSD rate. And prior to sending either 8 bits or 16 bits, currently the correct USB alternate interface has to be set, right? > Since 11.2MHz DSD is already on the horizon we may have to > change this to a single 8-bit raw interface and then vary the > underlying USB transfer sample rate between 1x, 2x, 4x 352.8kHz - Yes, especially given that if there's no common standard across different devices, either the drivers or the applications have to implement special handling code for this, and know which interface supports what. So for the ALSA layer, we should probably have a generic SND_PCM_FORMAT_DSD and then rely on the sample rate setting mechanisms to select the right DSD mode. Other solutions, like having a different SND_PCM_FORMAT_DSD_{2_8,5_6,11_2}_MHZ would be hairy to implement, as some devices need to get a sample rate update request, while others don't etc ... > that would be more logical and straight forward for the hardware > implementation. This is only supported through my own driver for the > Windows platform which uses the standard ASIO interface that supports > DSD at those rates. Since the Mac OS only supports PCM streams and > nothing else I brought together a bunch of DAC manufacturers and > playback software developers to standardize a method to "cannibalize" > the PCM stream for DSD data. The method is described in the attached > and is now supported by most manufacturers. Very interesting read. For ALSA though, it's no problem to support that in all layers and make the drivers tell applications about it. We just have to decide for a sane way :) > This also has been implemented on a few Linux platforms (Auraliti for > instance). Even though the DoP standard works really well so far, it > is a "bandaid" and should only be used if there is no other choice. Yes, understood. The thing is just that we shouldn't break exising solutions that already rely on this "bandaid". Daniel

1 0

[alsa-devel] ASoC: tegra: Does the PCM_TRIGGER_{PAUSE, RESUME} emulation really work?
by Lars-Peter Clausen 23 Mar '13

23 Mar '13

Hi, The tegra pcm driver tries to emulate SNDRV_PCM_TRIGGER_PAUSE and SNDRV_PCM_TRIGGER_RESUME. By passing SNDRV_PCM_TRIGGER_START and SNDRV_PCM_TRIGGER_STOP to snd_dmaengine_pcm_trigger. But does this really work? The old non-dmaengine based driver implemented this properly. I'd reset the dma position pointer for SNDRV_PCM_TRIGGER_START, but keep it where it was for SNDRV_PCM_TRIGGER_RESUME. But as far as I can see with the dmaengine based driver the pointer always gets reset to 0 for both SNDRV_PCM_TRIGGER_START and SNDRV_PCM_TRIGGER_RESUME. - Lars

2 2

Re: [alsa-devel] [PATCH V2] Sound: sgtl5000 Allow codec clock frequency to be set.
by Timur Tabi 22 Mar '13

22 Mar '13

On Fri, Mar 22, 2013 at 4:33 AM, Martin Fuzzey <mfuzzey(a)parkeon.com> wrote: > diff --git a/sound/soc/fsl/imx-sgtl5000.c b/sound/soc/fsl/imx-sgtl5000.c > index 424347e..71ce1f6 100644 > --- a/sound/soc/fsl/imx-sgtl5000.c > +++ b/sound/soc/fsl/imx-sgtl5000.c > @@ -128,18 +128,30 @@ static int imx_sgtl5000_probe(struct platform_device *pdev) > goto fail; > } > > + ret = of_property_read_u32(codec_np, "clock-frequency", > + &data->clk_frequency); I just noticed that you assign 'ret' here, but you never check the value. So I think you should either: 1) Check the value of 'ret' 2) Remove the "ret = "

1 0

[alsa-devel] [PATCH 0/2] ASoC: dmaengine_pcm: support generic DMA binding users
by Shawn Guo 22 Mar '13

22 Mar '13

The series adds a snd_dmaengine_generic_pcm_open() for users that adopt generic DMA binding and helplers. Vinod, AS per the request from Mark, I add the first patch to mark name parameter of dmaengine helpers as const, so that clients can mark const on their side. We need to have these two patches on a topic branch, as I've heard a few people converting their ASoC driver needing the patches. Can you ack the first patch, so that Mark can maintain them in a branch for anyone who needs it to pull? Shawn Guo (2): dmaengine: add const for name parameter ASoC: dmaengine_pcm: add snd_dmaengine_generic_pcm_open() drivers/dma/dmaengine.c | 2 +- drivers/dma/of-dma.c | 6 +++--- include/linux/dmaengine.h | 7 ++++--- include/linux/of_dma.h | 2 +- include/sound/dmaengine_pcm.h | 2 ++ sound/soc/soc-dmaengine-pcm.c | 39 +++++++++++++++++++++++++++++++++++++++ 6 files changed, 50 insertions(+), 8 deletions(-) -- 1.7.9.5

6 18

Re: [alsa-devel] [PATCH 0/3] ALSA: snd-usb: Some small fixes to make Playback Design products work
by Jussi Laako 22 Mar '13

22 Mar '13

On 03/22/2013 03:27 AM, Andreas Koch wrote: > I wouldn't worry about DSD wide, because that is a dead format that I > was involved in launching for professional recording applications more > than 10 years ago. It never took off. I just need it for my own purposes, but I can make custom stuff as necessary if there's no interest from others. Right now I'm just hoping to see a well defined common sample formats defined for ALSA that can be utilized by drivers. DoP could be implemented inside the driver or at ALSA layer instead of applications doing it. Not that I would mind, but I would find it cleaner than the current approach... :) Currently, ASIO is the only API to support DSD sample formats. I understand that Microsoft or Apple is a slow to turn giant, but I'd hope ALSA wouldn't be such. ;) There are already those IEC958 and DD/dts things being used for movie playback, so this wouldn't be such a big difference afterall. - Jussi

2 2

[alsa-devel] [PATCH] SoC: dma-sh7760: Fix compile error
by Lars-Peter Clausen 22 Mar '13

22 Mar '13

The dma-sh7760 currently fails with the following compile error: sound/soc/sh/dma-sh7760.c:346:2: error: unknown field 'pcm_ops' specified in initializer sound/soc/sh/dma-sh7760.c:346:2: warning: initialization from incompatible pointer type sound/soc/sh/dma-sh7760.c:347:2: error: unknown field 'pcm_new' specified in initializer sound/soc/sh/dma-sh7760.c:347:2: warning: initialization makes integer from pointer without a cast sound/soc/sh/dma-sh7760.c:348:2: error: unknown field 'pcm_free' specified in initializer sound/soc/sh/dma-sh7760.c:348:2: warning: initialization from incompatible pointer type sound/soc/sh/dma-sh7760.c: In function 'sh7760_soc_platform_probe': sound/soc/sh/dma-sh7760.c:353:2: warning: passing argument 2 of 'snd_soc_register_platform' from incompatible pointer type include/sound/soc.h:368:5: note: expected 'struct snd_soc_platform_driver *' but argument is of type 'struct snd_soc_platform *' This is due the misnaming of the snd_soc_platform_driver type name and 'ops' field. The issue was introduced in commit f0fba2a("ASoC: multi-component - ASoC Multi-Component Support"). Signed-off-by: Lars-Peter Clausen <lars(a)metafoo.de> --- Given that nobody noticed this over the course of the last three years the code is probably pretty dead by now anyway. --- sound/soc/sh/dma-sh7760.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/sound/soc/sh/dma-sh7760.c b/sound/soc/sh/dma-sh7760.c index 19eff8f..1a8b03e 100644 --- a/sound/soc/sh/dma-sh7760.c +++ b/sound/soc/sh/dma-sh7760.c @@ -342,8 +342,8 @@ static int camelot_pcm_new(struct snd_soc_pcm_runtime *rtd) return 0; } -static struct snd_soc_platform sh7760_soc_platform = { - .pcm_ops = &camelot_pcm_ops, +static struct snd_soc_platform_driver sh7760_soc_platform = { + .ops = &camelot_pcm_ops, .pcm_new = camelot_pcm_new, .pcm_free = camelot_pcm_free, }; -- 1.8.0

2 2

[alsa-devel] [PATCH 1/2] ASoC: compress - add support for metadata apis
by Vinod Koul 22 Mar '13

22 Mar '13

From: Jeeja KP <jeeja.kp(a)intel.com> Compress core added metadata apis in 9727b4, so add same in ASoC Signed-off-by: Jeeja KP <jeeja.kp(a)intel.com> Signed-off-by: Vinod Koul <vinod.koul(a)intel.com> --- Mark, Takashi: How do you guys wnat to take this one, Ideally this should go to mark's tree but the dependent apis are in takashi's tree, either way is fine with me :) --- sound/soc/soc-compress.c | 27 +++++++++++++++++++++++++++ 1 files changed, 27 insertions(+), 0 deletions(-) diff --git a/sound/soc/soc-compress.c b/sound/soc/soc-compress.c index 3ea7956..4730789 100644 --- a/sound/soc/soc-compress.c +++ b/sound/soc/soc-compress.c @@ -302,11 +302,38 @@ static int soc_compr_pointer(struct snd_compr_stream *cstream, return 0; } +static int sst_compr_set_metadata(struct snd_compr_stream *cstream, + struct snd_compr_metadata *metadata) +{ + struct snd_soc_pcm_runtime *rtd = cstream->private_data; + struct snd_soc_platform *platform = rtd->platform; + int ret = 0; + + if (platform->driver->compr_ops && platform->driver->compr_ops->pointer) + ret = platform->driver->compr_ops->set_metadata(cstream, metadata); + + return ret; +} + +static int sst_compr_get_metadata(struct snd_compr_stream *cstream, + struct snd_compr_metadata *metadata) +{ + struct snd_soc_pcm_runtime *rtd = cstream->private_data; + struct snd_soc_platform *platform = rtd->platform; + int ret = 0; + + if (platform->driver->compr_ops && platform->driver->compr_ops->pointer) + ret = platform->driver->compr_ops->get_metadata(cstream, metadata); + + return ret; +} /* ASoC Compress operations */ static struct snd_compr_ops soc_compr_ops = { .open = soc_compr_open, .free = soc_compr_free, .set_params = soc_compr_set_params, + .set_metadata = sst_compr_set_metadata, + .get_metadata = sst_compr_get_metadata, .get_params = soc_compr_get_params, .trigger = soc_compr_trigger, .pointer = soc_compr_pointer, -- 1.7.0.4

2 7

Re: [alsa-devel] 答复: 答复: how to combine mutil-channel in playback or capture?
by Daniel Mack 22 Mar '13

22 Mar '13

Hi, please don't top-post. On 22.03.2013 11:11, Zhang wei wrote: > But what is the mechanism to synchronize the data from different > channel,and maybe different channel pairs use different DMA buffer. You can try and see if syncing the individual, non-combinded PCM streams helps: http://www.alsa-project.org/alsa-doc/alsa-lib/pcm.html#pcm_sync > So, I guess ,about the combine ,according to the alsa.conf,the alsa-lib > opened the 4 devices(in my case) and got every channel paris’s data in > turns in a monent. And then combine them together in order as one frame? It will feed the input to all pcm streams. I don't really know if it uses the sync mechanism on that, but I'd guess so. > Because all the CODEC have the same clock timing,so the different DMA > buffer stored the different channel data for the same moment. Alsa-lib > obtains the same size data from each buffer in turns in once.repeat it > again and again. > > Right? Yes, and so the streams won't drift. Why don't you just go ahead and try it? You should play back some wav file with a test pattern which you can recognize on a DSO or IIS analyzer on the bus. Then see if they are in sync. Daniel

1 0

Re: [alsa-devel] 答复: how to combine mutil-channel in playback or capture?
by Daniel Mack 22 Mar '13

22 Mar '13

On 22.03.2013 10:23, Zhang wei wrote: > Thank you. Yes,you're right. I need 4 different stereo Codecs at > least more than one on my board and i think that will be more funy > than 1 Codec.In this case ,the struct snd_soc_card will be > initialized as following: Struct snd_soc_card test_card= { > .name=”Test Card”, .dai_link=&test_dai_codecs, .num_links=4; } As a > result ,there would be 4 devices named pcmC0Dnp(n=0,1,2,3) under the > directory /dev/snd. I wounder how and who combines the multi-channel > audio data togother? Is it the plugin ? Yes, you can use the alsa userspace for that. See http://www.alsa-project.org/main/index.php/Asoundrc Daniel

1 0

[alsa-devel] how to combine mutil-channel in playback or capture?
by Zhang wei 22 Mar '13

22 Mar '13

I have already achieved the alsa-driver which can playback and capture function with two channel. My board based on ARM9 which have 3 ADC & 1 DAC in IIS bus and all of them shared the same BCLK and LRCK. The pins figure Like this: _________________ | BCLK |___________ | | | LRCK |___________ | | | ADCDAT0 |___________ | | | ADCDAT1 |___________ | | | ADCDAT2 |___________ | | | DACDATA |___________ | | |_______________| Every ADCDATn(n=0,1,2) has two channel so the question is how can I get multi-channel audio data such as 4 or 6 in capture funciton? BR

2 1