gmane.linux.alsa.devel

Re: snd-usb endpoint rework

Felix Homann — 2012-05-26T06:40:46

2012/5/26 Grant Diffey <gdiffey< at >gmail.com>:

I have been confused about it, too. But that's just how the FTU works.
There are only 16 sends.


At least I have not.

Regards,
Felix

Re: snd-usb endpoint rework

Grant Diffey — 2012-05-26T04:19:26

[SNIP]

(sorry daniel you get two copies because I forgot to cc list and others


ok I just built a new kernel.

I started with 3.4 then applied the rt7 patches then merged the topic/misc
tree from sound (to get the ftu fixes from felix and daniel

so I have 3.4-rt7+sound/topic/misc

checkout v3.4 tag then apply the -rt patches using quiltapply then merge
sound/topic/misc

This all seems to be working ok. if I start jack with anything less that
128 samples It starts but I get no audio and lots of xruns (this is the
same as on previous kernel 3.4-rc4-rt5)

i've run jack_iodelay through a loopback (TRS from output 3 to input 3 on
the back of the FTU) for several hours without any problems

Felix,

the effects controls are not obvious to me I thought there were independent
fx sends for each output so expected 16x4 new controls plus the returns but
maybe that's not howitis.

also has anyone looked at how metering is reported on the wire?

Grant.

Dynamic PCM and Tegra AHUB

Stephen Warren — 2012-05-26T00:23:48

Mark, Liam,

Tegra30's AHUB is structured as follows:


Notes on the diagram:

Each FIFO above is a separate TX and RX FIFO. I merged them in the
drawing for simplicity, but they operate completely independently;
different memory packing formats, data flow rates, ...

The CIF can convert the audio format, e.g. mono<->stereo conversion and
change the # of bits in the data in pretty arbitrary combinations. This
is true for all CIFs; those that join the AHUB core to either the DMA
FIFOs or the I2S/SPDIF/DAM controllers.

The AHUB core is a complete cross-bar; each output selects 1 of the n
inputs.

The I2S and SPDIF controllers take audio from the AHUB, format it to the
appropriate protocol, and send to external IO (or the other way around).
The I2S and SPDIF modules don't perform any additional data
rate/width/channel conversion; the CIF must do whatever conversions are
needed.

The DAMs take 2 input channels from the AHUB, optionally perform some
sample rate conversion and/or bit size conversion beyond what t

[PATCH 15/15] ASoC: mxs-saif: Useclk_prepare_enable/clk_disable_unprepare

Fabio Estevam — 2012-05-25T23:14:56

From: Fabio Estevam <fabio.estevam< at >freescale.com>

Prepare the clock before enabling it.

Cc: Mark Brown <broonie< at >opensource.wolfsonmicro.com>
Cc: <alsa-devel< at >alsa-project.org>
Signed-off-by: Fabio Estevam <fabio.estevam< at >freescale.com>
---
 sound/soc/mxs/mxs-saif.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/sound/soc/mxs/mxs-saif.c b/sound/soc/mxs/mxs-saif.c
index aba71bf..15ad61a 100644
--- a/sound/soc/mxs/mxs-saif.c
+++ b/sound/soc/mxs/mxs-saif.c
< at >< at > -482,7 +482,7 < at >< at > static int mxs_saif_trigger(struct snd_pcm_substream *substream, int cmd,
 case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
 dev_dbg(cpu_dai->dev, "start\n");
 
-clk_enable(master_saif->clk);
+clk_prepare_enable(master_saif->clk);
 if (!master_saif->mclk_in_use)
 __raw_writel(BM_SAIF_CTRL_RUN,
 master_saif->base + SAIF_CTRL + MXS_SET_ADDR);
< at >< at > -492,7 +492,7 < at >< at > static int mxs_saif_trigger(struct snd_pcm_substream *substream, int cmd,
  * itself clk for its internal basic logic to work.
  */
 if (sa

Re: [PATCH] ASoC: imx-ssi: Use clk_prepare_enable()

Sascha Hauer — 2012-05-25T20:10:13

Hi Fabio,

On Fri, May 25, 2012 at 05:06:50PM -0300, Fabio Estevam wrote:

You should use clk_disable_unprepare then aswell.

Sascha

Help requested: new HSS1394 MIDI back-end

Sean M. Pappalardo - D.J. Pegasus — 2012-05-25T19:43:17

Hello everyone.

I am a developer for Mixxx, GPL cross-platform digital DJ software: 
http://www.mixxx.org. My focus is the controller subsystem. I am ready 
to finally add Linux support for HSS1394 DJ controllers such as 
Stanton's SCS.1m and SCS.1d.

HSS1394 is just MIDI over IEEE1394 (Firewire) at wire speed. The Windows 
and OSX library source code is LGPL and available on LaunchPad here: 
https://launchpad.net/hss1394

The Stanton SCS.1m is a sound interface integrated with a two-way 
control surface that speaks HSS1394. (The sound card uses an Oxford chip 
set and works fine with FFADO 2.0.1 today up to 96kHz. I use it with 
Mixxx via JACK.)

The Stanton SCS.1d is a two-way control surface (no sound card) that 
speaks HSS1394 and is capable of sending ALOT of latency-sensitive data: 
about 4000 messages per platter rotation. (Now imagine if you had four 
or even two of them on the same network running at +50% speed. This 
would quickly overwhelm USB, at least at the time these devices were 
designed.)

Re: [PATCH v5] sound/soc/lapis: add platform driver for ML7213

Vinod Koul — 2012-05-25T10:20:31

First you should not be writing your own dma driver, it *needs* to use
dmaenegine. We already have bunch of driver supported, so there may be a
case that existing driver works straight or with little modifications.
Using your own dma driver is a dead road, so sooner you move over better
it is.

One you move then it would be easy for you to use soc-dmaengine. If your
driver doesn't support cyclic; nothing stops from you emulating that in
S/W. And given that you have already contributed to dmaengine subsystem,
it should be easy for you :)

Re: [PATCH 2/4] ASoC: mmp: add audio dma support

Russell King - ARM Linux — 2012-05-25T09:42:31

This is where dealing with slave DMA channels in a virtualized setup
becomes a far better solution than trying to assign a particular
physical channel at request time.

What we may wish to think about is having a way for slave drivers to
assert to DMA engine the priority of a channel, which they can change
dynamically according to what they're doing.  Eg, an ALSA driver would
leave the channel low priority while it's not expecting to be used, but
as soon as we see the prepare call, set it to high priority.

The DMA engine driver could use that to decide to assign a physical
channel to the virtual channel, so that DMA can start as soon as
possible even with other activity on the DMA engine.

However, I've yet to see any setup where the number of physical DMA
channels available exceeds the number of actual _simultaneous_ users.
Even with the five channels on SA11x0 shared between 12? peripherals,
with my DMA engine driver I've only seen one or two physical channels
being used simultaneously.

Re: [PATCH v5] sound/soc/lapis: add platform driverfor ML7213

Tomoya MORINAGA — 2012-05-25T09:30:06

On Thu, May 24, 2012 at 7:07 PM, Mark Brown
<broonie< at >opensource.wolfsonmicro.com> wrote:

I'm not so familiar with Linux's DMA idea.
So we don't know whether non-cyclic dmaengine has problem or not.

Until now, we've developed device drivers use DMA driver like UART, SPI.
These drivers are  implemented using the same way, you called
"non-cyclic", and already applied.

As you said, common code for DMA code can be best solution.
However, currently, the code is nothing.
So, I want you to accept our driver as first step.
Because I think supporting new device is more important for linux than
dmaengine common.

thanks

Re: [PATCH 2/4] ASoC: mmp: add audio dma support

zhangfei gao — 2012-05-25T08:47:20

Thanks Russell and Vinod.

On Fri, May 25, 2012 at 4:05 PM, Russell King - ARM Linux <
linux< at >arm.linux.org.uk> wrote:

Will look into soc-dmaengine.



Do you mean at open time, like snd_dmaengine_pcm_open.
The channel resource is limited and better get dynamically.
As a  result the pcm_new and preallocate already called before.

Re: [PATCH 2/4] ASoC: mmp: add audio dma support

Russell King - ARM Linux — 2012-05-25T08:05:00

Note also...


This should be done at probe time, so we know the struct device, so
that...


... this uses the right device, and...


... we don't need crap like this.

Because then we'll be allocating buffers against the _right_ struct device
which is the DMA engine struct device.
--
To unsubscribe from this list: send the line "unsubscribe alsa-devel" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 2/4] ASoC: mmp: add audio dma support

Vinod Koul — 2012-05-25T07:53:36

Looks like this is *not* using soc-dmaengine library, why?

Re: To disable dma_area caching (twice)

Takashi Iwai — 2012-05-25T07:28:33

At Fri, 18 May 2012 14:18:57 +0900,
MASAO TAKAHASHI wrote:

The "right" fix would be to implement a proper dma_mmap_coherent() for
SH architecture.  It's found for ARM and some PPC variants, but for
neither SH nor MIPS.


thanks,

Takashi

[PATCH] ASoC: fsi: use PIO handler if DMA handler wasinvalid

Kuninori Morimoto — 2012-05-25T06:56:19

PIO handler is not good performance, but works on all platform.
So, switch to PIO handler if DMA handler was invalid case.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx< at >renesas.com>
---
 sound/soc/sh/fsi.c |   29 ++++++++++++++++++++---------
 1 files changed, 20 insertions(+), 9 deletions(-)

diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c
index 05582c1..0da021a 100644
--- a/sound/soc/sh/fsi.c
+++ b/sound/soc/sh/fsi.c
< at >< at > -247,7 +247,7 < at >< at > struct fsi_priv {
 struct fsi_stream_handler {
 int (*init)(struct fsi_priv *fsi, struct fsi_stream *io);
 int (*quit)(struct fsi_priv *fsi, struct fsi_stream *io);
-int (*probe)(struct fsi_priv *fsi, struct fsi_stream *io);
+int (*probe)(struct fsi_priv *fsi, struct fsi_stream *io, struct device *dev);
 int (*transfer)(struct fsi_priv *fsi, struct fsi_stream *io);
 int (*remove)(struct fsi_priv *fsi, struct fsi_stream *io);
 void (*start_stop)(struct fsi_priv *fsi, struct fsi_stream *io,
< at >< at > -571,16 +571,16 < at >< at > static int fsi_stream_transfer(struct fsi_

[PATCH] ASoC: fsi: bugfix: enable master clock controlon DMA stream

Kuninori Morimoto — 2012-05-25T06:55:11

DMA stream handler didn't care about master clock.
This patch fixes it up.

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx< at >renesas.com>
---
 sound/soc/sh/fsi.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/sound/soc/sh/fsi.c b/sound/soc/sh/fsi.c
index 7cee225..05582c1 100644
--- a/sound/soc/sh/fsi.c
+++ b/sound/soc/sh/fsi.c
< at >< at > -1172,9 +1172,14 < at >< at > static int fsi_dma_transfer(struct fsi_priv *fsi, struct fsi_stream *io)
 static void fsi_dma_push_start_stop(struct fsi_priv *fsi, struct fsi_stream *io,
  int start)
 {
+struct fsi_master *master = fsi_get_master(fsi);
+u32 clk  = fsi_is_port_a(fsi) ? CRA  : CRB;
 u32 enable = start ? DMA_ON : 0;
 
 fsi_reg_mask_set(fsi, OUT_DMAC, DMA_ON, enable);
+
+if (fsi_is_clk_master(fsi))
+fsi_master_mask_set(master, CLK_RST, clk, (enable) ? clk : 0);
 }
 
 static int fsi_dma_probe(struct fsi_priv *fsi, struct fsi_stream *io)

Re: [PATCH 1/5] ALSA: pcm: Add debug-print helperfunction

Takashi Iwai — 2012-05-25T06:19:44

At Thu, 24 May 2012 15:26:03 +0200,
Ola Lilja wrote:

Reviewed-by: Takashi Iwai <tiwai< at >suse.de>

Mark, Liam, feel free to pick it through your tree.


thanks,

Takashi

Re: [PATCH] [emu10k1]: remove the kcallloc cast(reported from make coccicheck's drop_kmalloc_cast.cocci)

Takashi Iwai — 2012-05-25T06:04:56

At Thu, 24 May 2012 19:32:29 +0530,
Devendra Naga wrote:

I don't think removing it improves anything much.
It's cast to __user pointer, and this rather helps to catch the
caution.


thanks,

Takashi

Re: [PATCH 1/2] ALSA: update sync header when streamsare linked/unlinked

Takashi Iwai — 2012-05-25T05:54:29

At Wed, 23 May 2012 13:57:34 -0500,
Pierre-Louis Bossart wrote:

Yes, that sounds like a reasonable solution.


thanks,

Takashi

Re: [PATCH 2/2 V2] ASoC: fix pxa-ssp compiling issueunder mach-mmp

Eric Miao — 2012-05-25T04:20:21

Part of job of #ifdef ... #endif, and cpu_is_pxa*() is to reduce code size when
the support for these SoCs are not compiled, but providing the overall
maintenance burden and ugliness, I'm fine with the changes here.

Acked-by: Eric Miao <eric.y.miao< at >gmail.com>

_______________________________________________
Alsa-devel mailing list
Alsa-devel< at >alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel

emu10k1 (Audigy) FXBus routing query

Dan Swain — 2012-05-25T01:12:05

Dear all,

I am writing to ask how to route certain DSP 'outputs' from my Audigy 2 ZS
back into the equivalent 'ASIO inputs' for recording purposes.

Specifically, I'd like to route outputs from the Wavetable Synths on my
card to inputs that would go straight into a DAW (such as Ardour), so that
I can apply effects, record and mix-down as if they were external synth
signals.

I know that with the kX project drivers in Windows this is possible, by
routing the Synth outputs to FXBus outputs 16-63, leaving the ASIO inputs
as 0-15 for the audio input, and then patching which channels I require
from the Synth to those inputs (e.g. Synth Channel 1 -> FXBus out 16&17 ->
FXBus in 0&1).

After reading a thread that contained responses from Jaroslav, I believe
the answer is in emufx.c, but I'm unsure as to where to start as I need to
assign the outputs from the Synths correctly first.

Thanks in advance! Any help would be greatly appreciated!

Kind Regards,

Dan

runtime change in plugin behaviour

Massimiliano Cialdi — 2012-05-24T14:58:36

Hi,

I have developed a plugin that implements a bi-quad filter. filter's 
parameters are given into asoundrc file.

Now I need to change those parameters during playback.
How can I do?
what help can gives alsalib to achieve this?

best regards

Max