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

[alsa-devel] [PATCH 0/7] ALSA: USB-audio: Support Zoom R16 playback
by Ricard Wanderlof 19 Oct '15

19 Oct '15

The Zoom R16 has a nonstandard playback format where each isochronous packet contains a length descriptor in the first four bytes. Curiously, capture data does not contain this and requires no quirk. The quirk involves adding the extra length descriptor whenever outgoing isochronous packets are generated, both in pcm.c (outgoing audio) and endpoint.c (silent data). The calculation for the max packet size in endpoint.c is also affected. This patch series refactors some code in pcm.c and endpoint.c before the actual quirk implementation. A commit then cleans up the entry in the quirks table. Tested with a Zoom R16, both separately using arecord and aplay (8 channel capture and 2 channel playback, respectively), as well as capture and playback together together using the Ardour digitial audio workstation application. The R24 reportedly is compatible with the R16, but I don't have access to one so I can't test it, and consequently the patch series only mentions the R16. Also tested using an Edirol UA-5 in both class compliant (16-bit) and "advanced" (24 bit, forces the use of quirks) modes in order to do some form of regression testing. Ricard Wanderlof (7): Break out copying to urb from prepare_playback_urb() Also move out hwptr_done wrap from prepare_playback_urb() Break out creation of silent urbs from prepare_outbound_urb() Add offset parameter to copy_to_urb() Add quirk for Zoom R16 playback Adjust max packet size calculation for tx_length_quirk Remove mixer entry from Zoom R16/24 quirk sound/usb/card.h | 1 + sound/usb/endpoint.c | 73 +++++++++++++++++++++++++++++++++-------------- sound/usb/pcm.c | 74 +++++++++++++++++++++++++++++++++++++----------- sound/usb/quirks-table.h | 14 +++------ sound/usb/quirks.c | 3 ++ sound/usb/stream.c | 1 + sound/usb/usbaudio.h | 1 + 7 files changed, 119 insertions(+), 48 deletions(-) -- 2.1.4

4 23

[alsa-devel] [PATCH 0/3] Add support for Cirrus Logic CS47L24 and WM1831 codecs
by Richard Fitzgerald 19 Oct '15

19 Oct '15

mfd patch based on Lee Jones's for-next gpio patch based on Linus Walleij's for-next ASoC patch based on Mark Brown's for-next Lee/Mark - can one of you take all three patches (with maintainer acks) so that the patch set is kept together? Richard Fitzgerald (3): mfd: arizona: Support Cirrus Logic CS47L24 and WM1831 gpio: arizona: Support Cirrus Logic CS47L24 and WM1831 ASoC: cs47l24: Add driver for Cirrus Logic CS47L24 and WM1831 codecs Documentation/devicetree/bindings/mfd/arizona.txt | 4 +- drivers/gpio/gpio-arizona.c | 4 + drivers/mfd/Kconfig | 19 +- drivers/mfd/Makefile | 3 + drivers/mfd/arizona-core.c | 72 +- drivers/mfd/arizona-irq.c | 40 +- drivers/mfd/arizona-spi.c | 7 + drivers/mfd/arizona.h | 4 + drivers/mfd/cs47l24-tables.c | 1629 +++++++++++++++++++++ include/linux/mfd/arizona/core.h | 3 + sound/soc/codecs/Kconfig | 8 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/cs47l24.c | 1147 +++++++++++++++ sound/soc/codecs/cs47l24.h | 23 + 14 files changed, 2940 insertions(+), 25 deletions(-) create mode 100644 drivers/mfd/cs47l24-tables.c create mode 100644 sound/soc/codecs/cs47l24.c create mode 100644 sound/soc/codecs/cs47l24.h -- 1.9.1

2 4

[alsa-devel] [patch] ALSA: firewire-tascam: off by one in identify_model()
by Dan Carpenter 19 Oct '15

19 Oct '15

In the original code, we potentially put a NUL character in model[8] and it caused a static checker warning. We can put the NUL in model[7] instead. Fixes: 53b3ffee7885 ('ALSA: firewire-tascam: change device probing processing') Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> diff --git a/sound/firewire/tascam/tascam.c b/sound/firewire/tascam/tascam.c index c6747a4..6ef2bcc 100644 --- a/sound/firewire/tascam/tascam.c +++ b/sound/firewire/tascam/tascam.c @@ -51,7 +51,7 @@ static int identify_model(struct snd_tscm *tscm) } /* Pick up model name from certain addresses. */ - for (i = 0; i < 8; i++) { + for (i = 0; i < 7; i++) { c = config_rom[28 + i / 4] >> (24 - 8 * (i % 4)); if (c == '\0') break;

3 6

[alsa-devel] [PATCH 0/3] ALSA: oxfw: add support for TASCAM FireOne
by Takashi Sakamoto 19 Oct '15

19 Oct '15

Hi, This parchset adds support for TASCAM FireOne to ALSA OXFW driver. PCM and MIDI functionalities become available including physical controls. The first and second patches are preparation for it. This model supports some extra commands. So as the other ALSA drivers for sound and music units on IEEE 1394 bus, they should be implemented in userspace applications. For your information, I note them: (Jog/Shuttle display mode) ./firewire-request /dev/fw1 fcp 0x01ff0000022e46493110ffff response: 000: 0c ff 00 00 02 2e 46 49 31 10 06 * The last byte is: * 0x00: always off * 0x01: always on * 0x02: breathe * 0x03: metronome * 0x04: MIDI clock rotate * 0x05: MIDI clock flash * 0x06: jog slow rotate * 0x07: Jog track (Control surface mode) ./firewire-request /dev/fw1 fcp 0x01ff0000022e46493111ffff response: 000: 0c ff 00 00 02 2e 46 49 31 11 00 * The last bytes is: * 0x00: FireOne native * 0x01: Mackie Human User Interface emulation (Input monitor monaural) ./firewire-request /dev/fw1 fcp 0x01ff0000022e46493112ffff response: 000: 0c ff 00 00 02 2e 46 49 31 12 00 * The last byte is: * 0x00: off * 0x01: on (Firmware version, read-only) ./firewire-request /dev/fw1 fcp 0x01ff0000022e46493113ffff response: 000: 0c ff 00 00 02 2e 46 49 31 13 02 * The last byte is: * 0x02: version 2 I can see additional commands from Windows driver. They seem to be used to retrieve the name of data channels. ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535460ff0000000040 response: 000: 0c ff 00 00 02 2e 48 53 54 60 ff 00 00 00 12 0c ......HST`...... response: 010: 41 75 64 69 6f 20 4f 75 74 20 4c 00 Audio Out L. ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535460ff0000010040 response: 000: 0c ff 00 00 02 2e 48 53 54 60 ff 00 00 01 12 0c ......HST`...... response: 010: 41 75 64 69 6f 20 4f 75 74 20 52 00 Audio Out R. ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535460ff0000020040 response: 000: 0c ff 00 00 02 2e 48 53 54 60 ff 00 00 02 12 09 ......HST`...... response: 010: 4d 69 64 69 20 4f 75 74 20 Midi Out ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535460ff0001000040 response: 000: 0c ff 00 00 02 2e 48 53 54 60 ff 00 01 00 12 0b ......HST`...... response: 010: 41 75 64 69 6f 20 49 6e 20 41 00 Audio In A. ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535460ff0001010040 response: 000: 0c ff 00 00 02 2e 48 53 54 60 ff 00 01 01 12 0b ......HST`...... response: 010: 41 75 64 69 6f 20 49 6e 20 42 00 Audio In B. ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535460ff0001020040 response: 000: 0c ff 00 00 02 2e 48 53 54 60 ff 00 01 02 12 08 ......HST`...... response: 010: 4d 69 64 69 20 49 6e 20 Midi In ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535470ff0000000040 response: 000: 0c ff 00 00 02 2e 48 53 54 70 ff 00 00 00 12 06 ......HSTp...... response: 010: 41 75 64 69 6f 20 Audio ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535470ff0000010040 response: 000: 0c ff 00 00 02 2e 48 53 54 70 ff 00 00 01 12 00 ......HSTp...... ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535470ff0000020040 response: 000: 0a ff 00 00 02 2e 48 53 54 70 ff 00 00 02 00 40 ......HSTp.....@ ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535470ff0001000040 response: 000: 0c ff 00 00 02 2e 48 53 54 70 ff 00 01 00 12 06 ......HSTp...... response: 010: 41 75 64 69 6f 20 Audio ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535470ff0001010040 response: 000: 0c ff 00 00 02 2e 48 53 54 70 ff 00 01 01 12 00 ......HSTp...... ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535470ff0001020040 response: 000: 0a ff 00 00 02 2e 48 53 54 70 ff 00 01 02 00 40 ......HSTp.....@ ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535460ff8100000040 response: 000: 0c ff 00 00 02 2e 48 53 54 60 ff 81 00 00 12 0c ......HST`...... response: 010: 4d 69 64 69 20 49 6e 20 4f 6e 65 00 Midi In One. ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535460ff8101000040 response: 000: 0c ff 00 00 02 2e 48 53 54 60 ff 81 01 00 12 0d ......HST`...... response: 010: 4d 69 64 69 20 4f 75 74 20 4f 6e 65 00 Midi Out One. ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535460ff8200000040 response: 000: 0c ff 00 00 02 2e 48 53 54 60 ff 82 00 00 12 0c ......HST`...... response: 010: 4d 69 64 69 20 49 6e 20 54 77 6f 00 Midi In Two. ./firewire-request /dev/fw1 fcp 0x01ff0000022e48535460ff8201000040 response: 000: 0c ff 00 00 02 2e 48 53 54 60 ff 82 01 00 12 0d ......HST`...... response: 010: 4d 69 64 69 20 4f 75 74 20 54 77 6f 00 Midi Out Two. Takashi Sakamoto (3): ALSA: oxfw: calculating MIDI ports in stream discover ALSA: oxfw: support more MIDI ports ALSA: oxfw: add an entry for TASCAM FireOne sound/firewire/oxfw/oxfw-midi.c | 24 +++--------------------- sound/firewire/oxfw/oxfw-stream.c | 37 +++++++++++++++++++++++++++++++++++-- sound/firewire/oxfw/oxfw.c | 17 +++++++++++++++++ 3 files changed, 55 insertions(+), 23 deletions(-) -- 2.1.4

2 5

[alsa-devel] [PATCH v3] drm/i915: Improve kernel-doc for i915_audio_component struct
by David Henningsson 19 Oct '15

19 Oct '15

Signed-off-by: David Henningsson <david.henningsson(a)canonical.com> --- Now rebased against drm-intel git master. include/drm/i915_component.h | 69 ++++++++++++++++++++++++++++++++------------ 1 file changed, 51 insertions(+), 18 deletions(-) diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h index 30d89e0..fab1385 100644 --- a/include/drm/i915_component.h +++ b/include/drm/i915_component.h @@ -31,47 +31,80 @@ #define MAX_PORTS 5 /** - * struct i915_audio_component_ops - callbacks defined in gfx driver - * @owner: the module owner - * @get_power: get the POWER_DOMAIN_AUDIO power well - * @put_power: put the POWER_DOMAIN_AUDIO power well - * @codec_wake_override: Enable/Disable generating the codec wake signal - * @get_cdclk_freq: get the Core Display Clock in KHz - * @sync_audio_rate: set n/cts based on the sample rate + * struct i915_audio_component_ops - Ops implemented by i915 driver, called by hda driver */ struct i915_audio_component_ops { + /** + * @owner: i915 module + */ struct module *owner; + /** + * @get_power: get the POWER_DOMAIN_AUDIO power well + * + * Request the power well to be turned on. + */ void (*get_power)(struct device *); + /** + * @put_power: put the POWER_DOMAIN_AUDIO power well + * + * Allow the power well to be turned off. + */ void (*put_power)(struct device *); + /** + * @codec_wake_override: Enable/disable codec wake signal + */ void (*codec_wake_override)(struct device *, bool enable); + /** + * @get_cdclk_freq: Get the Core Display Clock in kHz + */ int (*get_cdclk_freq)(struct device *); + /** + * @sync_audio_rate: set n/cts based on the sample rate + * + * Called from audio driver. After audio driver sets the + * sample rate, it will call this function to set n/cts + */ int (*sync_audio_rate)(struct device *, int port, int rate); }; +/** + * struct i915_audio_component_audio_ops - Ops implemented by hda driver, called by i915 driver + */ struct i915_audio_component_audio_ops { + /** + * @audio_ptr: Pointer to be used in call to pin_eld_notify + */ void *audio_ptr; /** - * Call from i915 driver, notifying the HDA driver that - * pin sense and/or ELD information has changed. - * @audio_ptr: HDA driver object - * @port: Which port has changed (PORTA / PORTB / PORTC etc) + * @pin_eld_notify: Notify the HDA driver that pin sense and/or ELD information has changed + * + * Called when the i915 driver has set up audio pipeline or has just + * begun to tear it down. This allows the HDA driver to update its + * status accordingly (even when the HDA controller is in power save + * mode). */ void (*pin_eld_notify)(void *audio_ptr, int port); }; /** - * struct i915_audio_component - used for audio video interaction - * @dev: the device from gfx driver - * @aud_sample_rate: the array of audio sample rate per port - * @ops: callback for audio driver calling - * @audio_ops: Call from i915 driver + * struct i915_audio_component - Used for direct communication between i915 and hda drivers */ struct i915_audio_component { + /** + * @dev: i915 device, used as parameter for ops + */ struct device *dev; + /** + * @aud_sample_rate: the array of audio sample rate per port + */ int aud_sample_rate[MAX_PORTS]; - + /** + * @ops: Ops implemented by i915 driver, called by hda driver + */ const struct i915_audio_component_ops *ops; - + /** + * @audio_ops: Ops implemented by hda driver, called by i915 driver + */ const struct i915_audio_component_audio_ops *audio_ops; }; -- 1.9.1

2 1

[alsa-devel] [PATCH 0/5] ALSA: firewire: suppress sparse warnings due to endianness handling
by Takashi Sakamoto 19 Oct '15

19 Oct '15

Hi, This patchset fixes some issues related to sparse warnings about endianness handling for ALSA firewire stack. For writing this patchset, I use 'C=1 CF=-D__CHECK_ENDIAN__' options to 'make' command. If they're not enough, please inform to me. Takashi Sakamoto (5): ALSA: dice: correct variable types for __be32 data ALSA: dice: assign converted data to the same type of variable ALSA: fireworks: use u32 type for be32_to_cpup() macro ALSA: bebob: use correct type for __be32 data ALSA: firewire-digi00x/firewire-tascam: remove wrong conversion for Config ROM sound/firewire/bebob/bebob_maudio.c | 2 +- sound/firewire/dice/dice-stream.c | 12 ++++++------ sound/firewire/dice/dice.c | 3 ++- sound/firewire/digi00x/digi00x.c | 3 +-- sound/firewire/fireworks/fireworks_command.c | 2 +- sound/firewire/tascam/tascam.c | 3 +-- 6 files changed, 12 insertions(+), 13 deletions(-) -- 2.1.4

2 6

[alsa-devel] [PATCH] ALSA: firewire-lib: avoid NULL pointer dereference after closing MIDI port
by Takashi Sakamoto 19 Oct '15

19 Oct '15

When asynchronous MIDI port is closed before callbacked, the callback function causes NULL pointer dereference to missing MIDI substream. This commit fixes this bug. Fixes: e8a40d9bcb23('ALSA: firewire-lib: schedule work again when MIDI substream has rest of MIDI messages') Reported-by: Dan Carpenter <dan.carpenter(a)oracle.com> Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/lib.c | 6 +++++- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/sound/firewire/lib.c b/sound/firewire/lib.c index edf1c8b..f80aafa 100644 --- a/sound/firewire/lib.c +++ b/sound/firewire/lib.c @@ -74,7 +74,11 @@ static void async_midi_port_callback(struct fw_card *card, int rcode, struct snd_fw_async_midi_port *port = callback_data; struct snd_rawmidi_substream *substream = ACCESS_ONCE(port->substream); - if (rcode == RCODE_COMPLETE && substream != NULL) + /* This port is closed. */ + if (substream == NULL) + return; + + if (rcode == RCODE_COMPLETE) snd_rawmidi_transmit_ack(substream, port->consume_bytes); else if (!rcode_is_permanent_error(rcode)) /* To start next transaction immediately for recovery. */ -- 2.1.4

2 1

[alsa-devel] [PATCH v6 1/4] drm/i915: Add audio sync_audio_rate callback
by libin.yang＠intel.com 19 Oct '15

19 Oct '15

From: Libin Yang <libin.yang(a)intel.com> Add the sync_audio_rate callback. With the callback, audio driver can trigger i915 driver to set the proper N/CTS or N/M based on different sample rates. Signed-off-by: Libin Yang <libin.yang(a)intel.com> --- include/drm/i915_component.h | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/include/drm/i915_component.h b/include/drm/i915_component.h index c9a8b64..8ad6f1b 100644 --- a/include/drm/i915_component.h +++ b/include/drm/i915_component.h @@ -33,6 +33,13 @@ struct i915_audio_component { void (*put_power)(struct device *); void (*codec_wake_override)(struct device *, bool enable); int (*get_cdclk_freq)(struct device *); + /** + * @sync_audio_rate: set n/cts based on the sample rate + * + * Called from audio driver. After audio driver sets the + * sample rate, it will call this function to set n/cts + */ + int (*sync_audio_rate)(struct device *, int port, int rate); } *ops; }; -- 1.9.1

5 20

[alsa-devel] audio-over-SPI driver for ASoC
by Brian Clarkson 18 Oct '15

18 Oct '15

Hi I'm about to embark on the development of an ASoC capture driver that uses SPI to stream the samples to the processor. I'm still spending a lot of my time going through the ALSA kernel code but as I do that may I have some suggestions as to which examples would be closest to my case? My development hardware is AM335x --> McSPI --> ADS8868. So far I think I have achieved a solid understanding of the "simple-card" case where you have dai-link that connects a processor peripheral driver (e.g. McASP ) with a codec driver and forms a snd_soc_card that can be registered. Is my best option to: - write a new CPU DAI (snd_soc_dai_driver) based on the existing SPI driver - write a new CODEC DAI (snd_soc_dai_driver) which will be mostly empty - write a new platform driver that populates and registers a new snd_soc_card struct with the above in a dai_link? Any advice would be much appreciated. Cheers, Brian -- Orthogonal Devices Tokyo, Japan www.orthogonaldevices.com +81 80 8700 2340

2 1

[alsa-devel] [PATCH 0/3] fix sending the same MIDI bytes in two transactions
by Takashi Sakamoto 18 Oct '15

18 Oct '15

Hi, In former commits, MIDI functionality is added to TASCAM driver, while it includes a bug to send the same MIDI bytes in two continuous transactions. This patchset is to fix this bug, including some code improvements. Takashi Sakamoto (3): ALSA: tascam: remove buffer initialization in driver side ALSA: tascam: improve loop condition to filling MIDI bytes in transaction ALSA: tascam: clear extra MIDI byte of asynchronous transaction sound/firewire/tascam/tascam-transaction.c | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) -- 2.1.4

2 7