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

[alsa-devel] [PATCH 0/6 v3] ALSA: firewire-digi00x: support MIDI functionality
by Takashi Sakamoto 12 Oct '15

12 Oct '15

Hi, This commit updates my former post (patch 13, 15, 16): [alsa-devel] [PATCH 00/25 v2] ALSA: support AMDTP variants http://mailman.alsa-project.org/pipermail/alsa-devel/2015-August/096739.html Digi 00x driver may be newly available in Linux 4.4. This patchset adds ALSA MIDI ports to support physical MIDI ports and physical controls. I tested physical MIDI ports, while never tested physical controls because I'm not an owner of 'console' models. The functionality for physical controls is written according to my assumption. When I investigated Digi 002 rack, Windows driver registers a certain address to the device, and adds virtual MIDI ports to the system. These ports are named as 'control'. When MIDI application sends MIDI messages to the port, asynchronous transactions start on IEEE 1394 bus. On the other hand, I have no way to confirm asynchronous transaction in opposite direction because the rack model doesn't have the functionality. In this time, I apply the same format of outgoing asynchronous transaction to incoming asynchronous transaction. Takashi Sakamoto (6): firewire-digi00x: use in-kernel representation for the type of 8 bits firewire-digi00x: handle MIDI messages in isochronous packets firewire-digi00x: add support for MIDI ports corresponding to isochronous packet streaming firewire-digi00x: add support of asynchronous transaction for incoming MIDI messages from physical controls firewire-digi00x: add support of asynchronous transaction for outgoing MIDI messages to physical controls firewire-digi00x: add support for MIDI ports for physical controls sound/firewire/digi00x/Makefile | 2 +- sound/firewire/digi00x/amdtp-dot.c | 150 +++++++++++++++++++++---- sound/firewire/digi00x/digi00x-midi.c | 160 +++++++++++++++++++++++++++ sound/firewire/digi00x/digi00x-stream.c | 6 +- sound/firewire/digi00x/digi00x-transaction.c | 70 ++++++++++-- sound/firewire/digi00x/digi00x.c | 4 + sound/firewire/digi00x/digi00x.h | 15 ++- 7 files changed, 376 insertions(+), 31 deletions(-) create mode 100644 sound/firewire/digi00x/digi00x-midi.c -- 2.1.4

2 8

[alsa-devel] [RESEND PATCH 1/1] Allow any MIDI endpoint to drive use of interrupt transfer on newer Roland devices
by maillist＠superlative.org 11 Oct '15

11 Oct '15

From: "Keith A. Milner" <maillist(a)superlative.org> This patch enables interrupt transfer mode for MIDI ports on newer Boss/Roland devices such as the GT-100/001 which support interrupt transfer on both IN and OUT MIDI endpoints. Previously this wasn't being enabled for these devices as the code was specifically looking for the scenario where the IN endpoint supported interrupt transfer and the OUT endpoint was bulk transfer. Newer devices support interrupt transfer for both endpoints. This has been tested on Boss devices GT-001, BR-80 and JS-8 and Roland VS-20. It would benefit from some regresison testing with other devices if possible. Signed-off-by: Keith A. Milner <maillist(a)superlative.org> diff --git a/sound/usb/midi.c b/sound/usb/midi.c index b901f46..d50c649 100644 --- a/sound/usb/midi.c +++ b/sound/usb/midi.c @@ -1860,9 +1860,14 @@ static void snd_usbmidi_switch_roland_altsetting(struct snd_usb_midi* umidi) hostif = &intf->altsetting[1]; intfd = get_iface_desc(hostif); + /* If either or both of the endpoints support interrupt transfer, + * then use the alternate setting + */ if (intfd->bNumEndpoints != 2 || - (get_endpoint(hostif, 0)->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) != USB_ENDPOINT_XFER_BULK || - (get_endpoint(hostif, 1)->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) != USB_ENDPOINT_XFER_INT) + !((get_endpoint(hostif, 0)->bmAttributes + & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT || + (get_endpoint(hostif, 1)->bmAttributes + & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT)) return; snd_printdd(KERN_INFO "switching to altsetting %d with int ep\n", -- 1.9.1

3 5

[alsa-devel] [PATCH v3] ALSA: usb-audio: Fix max packet size calculation for USB audio
by Ricard Wanderlof 11 Oct '15

11 Oct '15

Rounding must take place before multiplication with the frame size, since each packet contains a whole number of frames. We must also properly consider the data interval, as a larger data interval will result in larger packets, which, depending on the sampling frequency, can result in packet sizes that are less than integral multiples of the packet size for a lower data interval. Tested with an Edirol UA-5 both at 44.1 kHz and 96 kHz. Signed-off-by: Ricard Wanderlof <ricardw(a)axis.com> --- V2: Added tested device to commit message. No other changes. V3: Updated after input from Clemens. Since the expression is now getting rather convoluted, added a description in the comments in the code. New commit message to reflect the new version. Updated rationale below. The code as it stands has the following expression on line 613 to calculate the maximum isochronous packet size: maxsize = ((ep->freqmax + 0xffff) * (frame_bits >> 3)) >> (16 - ep->datainterval); Here, ep->freqmax is the maximum assumed sample frequency, calculated from the nominal sample frequency plus 25%. It is ultimately derived from ep->freqn, which is in the units of frames per packet, from get_usb_full_speed_rate() or usb_high_speed_rate(), as applicable, in Q16.16 format. The expression essentially adds the Q16.16 equivalent of 0.999... (i.e. the largest number less than one) to the sample rate, in order to get a rate whose integer part is rounded up from the fractional value. The multiplication with (frame_bits >> 3) yields the number of bytes in a packet, and the (16 >> ep->datainterval) then converts it from Q16.16 back to an integer, taking into consideration the bDataInterval field of the endpoint descriptor (which describes how often isochronous packets are transmitted relative to the (micro)frame rate (125us or 1ms, for USB high speed and full speed, respectively)). For this discussion we will initially assume a bDataInterval of 0, so the second line of the expression just converts the Q16.16 value to an integer. In order to illustrate the problem, we will set frame_bits 64, which corresponds to a frame size of 8 bytes. The problem here is twofold. First, the rounding operation consists of the addition of 0x0.ffff and subsequent conversion to integer, but as the expression stands, the conversion to integer is done after multiplication with the frame size, rather than before. This results in the resulting maxsize becoming too large. Let's take an example. We have a sample rate of 96 kHz, so our ep->freqn is 0xc0000 (see usb_high_speed_rate()). Add 25% (line 612) and we get 0xf0000. The calculated maxsize is then ((0xf0000 + 0x0ffff) * 8) >> 16 = 127 . However, if we do the number of bytes calculation in a less obscure way it's more apparent what the true corresponding packet size is: we get ceil(96000 * 1.25 / 8000) * 8 = 120, where 1.25 is the 25% from line 612, and the 8000 is the number of isochronous packets per second on a high speed USB connection (125 us microframe interval). This is fixed by performing the complete rounding operation prior to multiplication with the frame rate. The second problem is that when considering the ep->datainterval, this must be done before rounding, in order to take the advantage of the fact that the number of bytes per packet is not an integer, the resulting rounded-up integer is not necessarily a factor of two when the data interval is increased by the same factor. For instance, assuming a freqency of 41 kHz, the resulting bytes-per-packet value for USB high speed is 41 kHz / 8000 = 5.125, or 0x52000 in Q16.16 format. With a data interval of 1 (ep->datainterval = 0), this 6 frames per packet is required, whereas with a data interval of 2 we need 10.25, i.e. 11 frames needed. Rephrasing the maxsize expression to: maxsize = (((ep->freqmax << ep->datainterval) + 0xffff) >> 16) * (frame_bits >> 3); for the above 96 kHz example we instead get ((0xf0000 + 0xffff) >> 16) * 8 = 120 which is the correct value. We can also do the calculation with a non-integer sample rate which is when rounding comes into effect: say we have 44.1 kHz (resulting ep->freqn = 0x58333, and resulting ep->freqmax 0x58333 * 1.25 = 0x6e3ff (rounded down)): Original maxsize = ((0x6e3ff + 0xffff) * 8) << 16 = 63 (63.124.. rounded down) True maxsize = ceil(44100 * 1.25 / 8000) * 8 = 7 * 8 = 56 New maxsize = ((0x6e3ff + 0xffff) >> 16) * 8 = 7 * 8 = 56 This is also corroborated by the wMaxPacketSize check on line 616. Assume that wMaxPacketSize = 104, with ep->maxpacksize then having the same value. As 104 < 127, we get maxsize = 104. ep->freqmax is then recalculated to (104 / 8) << 16 = 0xd0000 . Putting that rate into the original maxsize calculation yields a maxsize of ((0xd0000 + 0xffff) * 8) >> 16 = 111 (with decimals 111.99988). Clearly, we should get back the 104 here, which we would with the new expression: ((0xd0000 + 0xffff) >> 16) * 8 = 104 . As it currently stands, the error is tolerable because it only results in maxsize being a bit too big which wastes a couple of bytes, either as a result of the first maxsize calculation, or because the resulting calculation will hit the wMaxPacketSize value before the packet is too big, resulting in fixing the size to wMaxPacketSize even though the packet is actually not too long. However, I'm working on a quirk for a device which stuffs an extra four (non sample) bytes into each isochronous packet, and that means that the maxsize calculation must take this into account. During this work it became obvious that there was something wrong with the maxsize calculation, as the resulting packet size when wMaxPacketSize was hit did not correspond to the packet size which triggered the if statement to start with. Since this seems to me an obvious (after looking at it for a bit...) bug I'm submitting this as a separate patch rather than part of an upcoming patch series. sound/usb/endpoint.c | 19 +++++++++++++++++-- 1 file changed, 17 insertions(+), 2 deletions(-) diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c index e6f7189..a77d9c8 100644 --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -610,8 +610,23 @@ static int data_ep_set_params(struct snd_usb_endpoint *ep, /* assume max. frequency is 25% higher than nominal */ ep->freqmax = ep->freqn + (ep->freqn >> 2); - maxsize = ((ep->freqmax + 0xffff) * (frame_bits >> 3)) - >> (16 - ep->datainterval); + /* Round up freqmax to nearest integer in order to calculate maximum + * packet size, which must represent a whole number of frames. + * This is accomplished by adding 0x0.ffff before converting the + * Q16.16 format into integer. + * In order to accurately calculate the maximum packet size when + * the data interval is more than 1 (i.e. ep->datainterval > 0), + * multiply by the data interval prior to rounding. For instance, + * a freqmax of 41 kHz will result in a max packet size of 6 (5.125) + * frames with a data interval of 1, but 11 (10.25) frames with a + * data interval of 2. + * (ep->freqmax << ep->datainterval overflows at 8.192 MHz for the + * maximum datainterval value of 3, at USB full speed, higher for + * USB high speed, noting that ep->freqmax is in units of + * frames per packet in Q16.16 format.) + */ + maxsize = (((ep->freqmax << ep->datainterval) + 0xffff) >> 16) * + (frame_bits >> 3); /* but wMaxPacketSize might reduce this */ if (ep->maxpacksize && ep->maxpacksize < maxsize) { /* whatever fits into a max. size packet */ -- 1.7.10.4 -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 3

[alsa-devel] [PATCH] ALSA: firewire-lib: continue packet processing at detecting wrong CIP headers
by Takashi Sakamoto 11 Oct '15

11 Oct '15

In firewire-lib, isochronous packet streaming is stopped when detecting wrong value for FMT field of CIP headers. Although this is appropriate to IEC 61883-1 and 6, some BeBoB based devices with vendors' customization use invalid value to FMT field of CIP headers in the beginning of streaming. $ journalctl snd-bebob fw1.0: Detect unexpected protocol: 01000000 8000ffff I got this log with M-Audio FireWire 1814. In this line, the value of FMT field is 0x00, while it should be 0x10 in usual AMDTP. Except for the beginning, these devices continue to transfer packets with valid value for FMT field, except for the beginning. Therefore, in this case, firewire-lib should continue to process packets. The former implementation of firewire-lib performs it. This commit loosens the handling of wrong value, to continue packet processing in the case. Fixes: 414ba022a528('ALSA: firewire-lib: add support arbitrary value for fmt/fdf fields in CIP header') Signed-off-by: Takashi Sakamoto <o-takashi(a)sakamocchi.jp> --- sound/firewire/amdtp-stream.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/sound/firewire/amdtp-stream.c b/sound/firewire/amdtp-stream.c index fa10b58..ed29026 100644 --- a/sound/firewire/amdtp-stream.c +++ b/sound/firewire/amdtp-stream.c @@ -468,10 +468,12 @@ static int handle_in_packet(struct amdtp_stream *s, /* Check valid protocol or not. */ fmt = (cip_header[1] & CIP_FMT_MASK) >> CIP_FMT_SHIFT; if (fmt != s->fmt) { - dev_err(&s->unit->device, - "Detect unexpected protocol: %08x %08x\n", - cip_header[0], cip_header[1]); - return -EIO; + dev_info_ratelimited(&s->unit->device, + "Detect unexpected protocol: %08x %08x\n", + cip_header[0], cip_header[1]); + *data_blocks = 0; + pcm_frames = 0; + goto end; } /* Calculate data blocks */ -- 2.1.4

2 1

[alsa-devel] [PATCH] ALSA: bebob: constify snd_bebob_rate_spec structures
by Julia Lawall 11 Oct '15

11 Oct '15

The snd_bebob_rate_spec structure type contains only function pointers. In all instances of this structure type, the functions are provided statically and are never changed subsequently. Add a const annotation on all initializations and uses. Done with the help of Coccinelle. Signed-off-by: Julia Lawall <Julia.Lawall(a)lip6.fr> --- sound/firewire/bebob/bebob.c | 2 +- sound/firewire/bebob/bebob.h | 2 +- sound/firewire/bebob/bebob_focusrite.c | 4 ++-- sound/firewire/bebob/bebob_maudio.c | 4 ++-- sound/firewire/bebob/bebob_pcm.c | 2 +- sound/firewire/bebob/bebob_proc.c | 2 +- sound/firewire/bebob/bebob_stream.c | 2 +- sound/firewire/bebob/bebob_terratec.c | 2 +- sound/firewire/bebob/bebob_yamaha.c | 2 +- 9 files changed, 11 insertions(+), 11 deletions(-) diff --git a/sound/firewire/bebob/bebob_yamaha.c b/sound/firewire/bebob/bebob_yamaha.c index 5810170..2a9ffdb 100644 --- a/sound/firewire/bebob/bebob_yamaha.c +++ b/sound/firewire/bebob/bebob_yamaha.c @@ -51,7 +51,7 @@ static struct snd_bebob_clock_spec clock_spec = { .types = clk_src_types, .get = &clk_src_get, }; -static struct snd_bebob_rate_spec rate_spec = { +static const struct snd_bebob_rate_spec rate_spec = { .get = &snd_bebob_stream_get_rate, .set = &snd_bebob_stream_set_rate, }; diff --git a/sound/firewire/bebob/bebob_focusrite.c b/sound/firewire/bebob/bebob_focusrite.c index a1a3949..e62923e 100644 --- a/sound/firewire/bebob/bebob_focusrite.c +++ b/sound/firewire/bebob/bebob_focusrite.c @@ -260,7 +260,7 @@ saffire_meter_get(struct snd_bebob *bebob, u32 *buf, unsigned int size) return err; } -static struct snd_bebob_rate_spec saffirepro_both_rate_spec = { +static const struct snd_bebob_rate_spec saffirepro_both_rate_spec = { .get = &saffirepro_both_clk_freq_get, .set = &saffirepro_both_clk_freq_set, }; @@ -287,7 +287,7 @@ struct snd_bebob_spec saffirepro_10_spec = { .meter = NULL }; -static struct snd_bebob_rate_spec saffire_both_rate_spec = { +static const struct snd_bebob_rate_spec saffire_both_rate_spec = { .get = &snd_bebob_stream_get_rate, .set = &snd_bebob_stream_set_rate, }; diff --git a/sound/firewire/bebob/bebob.c b/sound/firewire/bebob/bebob.c index 0ed5e5f..091290d 100644 --- a/sound/firewire/bebob/bebob.c +++ b/sound/firewire/bebob/bebob.c @@ -335,7 +335,7 @@ static void bebob_remove(struct fw_unit *unit) snd_card_free_when_closed(bebob->card); } -static struct snd_bebob_rate_spec normal_rate_spec = { +static const struct snd_bebob_rate_spec normal_rate_spec = { .get = &snd_bebob_stream_get_rate, .set = &snd_bebob_stream_set_rate }; diff --git a/sound/firewire/bebob/bebob.h b/sound/firewire/bebob/bebob.h index d3c9d8d..aff9da3 100644 --- a/sound/firewire/bebob/bebob.h +++ b/sound/firewire/bebob/bebob.h @@ -71,7 +71,7 @@ struct snd_bebob_meter_spec { }; struct snd_bebob_spec { struct snd_bebob_clock_spec *clock; - struct snd_bebob_rate_spec *rate; + const struct snd_bebob_rate_spec *rate; struct snd_bebob_meter_spec *meter; }; diff --git a/sound/firewire/bebob/bebob_terratec.c b/sound/firewire/bebob/bebob_terratec.c index 9242e33..470d526 100644 --- a/sound/firewire/bebob/bebob_terratec.c +++ b/sound/firewire/bebob/bebob_terratec.c @@ -55,7 +55,7 @@ phase24_series_clk_src_get(struct snd_bebob *bebob, unsigned int *id) return 0; } -static struct snd_bebob_rate_spec phase_series_rate_spec = { +static const struct snd_bebob_rate_spec phase_series_rate_spec = { .get = &snd_bebob_stream_get_rate, .set = &snd_bebob_stream_set_rate, }; diff --git a/sound/firewire/bebob/bebob_pcm.c b/sound/firewire/bebob/bebob_pcm.c index 2fdc1f1..ef224d6 100644 --- a/sound/firewire/bebob/bebob_pcm.c +++ b/sound/firewire/bebob/bebob_pcm.c @@ -155,7 +155,7 @@ static int pcm_open(struct snd_pcm_substream *substream) { struct snd_bebob *bebob = substream->private_data; - struct snd_bebob_rate_spec *spec = bebob->spec->rate; + const struct snd_bebob_rate_spec *spec = bebob->spec->rate; unsigned int sampling_rate; enum snd_bebob_clock_type src; int err; diff --git a/sound/firewire/bebob/bebob_stream.c b/sound/firewire/bebob/bebob_stream.c index a2baa47..fc7a66d 100644 --- a/sound/firewire/bebob/bebob_stream.c +++ b/sound/firewire/bebob/bebob_stream.c @@ -580,7 +580,7 @@ end: int snd_bebob_stream_start_duplex(struct snd_bebob *bebob, unsigned int rate) { - struct snd_bebob_rate_spec *rate_spec = bebob->spec->rate; + const struct snd_bebob_rate_spec *rate_spec = bebob->spec->rate; struct amdtp_stream *master, *slave; enum cip_flags sync_mode; unsigned int curr_rate; diff --git a/sound/firewire/bebob/bebob_maudio.c b/sound/firewire/bebob/bebob_maudio.c index 057495d..dc9cd0c 100644 --- a/sound/firewire/bebob/bebob_maudio.c +++ b/sound/firewire/bebob/bebob_maudio.c @@ -712,7 +712,7 @@ end: } /* for special customized devices */ -static struct snd_bebob_rate_spec special_rate_spec = { +static const struct snd_bebob_rate_spec special_rate_spec = { .get = &special_get_rate, .set = &special_set_rate, }; @@ -733,7 +733,7 @@ struct snd_bebob_spec maudio_special_spec = { }; /* Firewire 410 specification */ -static struct snd_bebob_rate_spec usual_rate_spec = { +static const struct snd_bebob_rate_spec usual_rate_spec = { .get = &snd_bebob_stream_get_rate, .set = &snd_bebob_stream_set_rate, }; diff --git a/sound/firewire/bebob/bebob_proc.c b/sound/firewire/bebob/bebob_proc.c index 301cc6a..0f3b2ca 100644 --- a/sound/firewire/bebob/bebob_proc.c +++ b/sound/firewire/bebob/bebob_proc.c @@ -138,7 +138,7 @@ proc_read_clock(struct snd_info_entry *entry, "SYT-Match", }; struct snd_bebob *bebob = entry->private_data; - struct snd_bebob_rate_spec *rate_spec = bebob->spec->rate; + const struct snd_bebob_rate_spec *rate_spec = bebob->spec->rate; struct snd_bebob_clock_spec *clk_spec = bebob->spec->clock; enum snd_bebob_clock_type src; unsigned int rate;

3 8

[alsa-devel] [PATCH 1/1] Allow any MIDI endpoint to drive use of interrupt transfer on Roland devices
by maillist＠superlative.org 11 Oct '15

11 Oct '15

From: "Keith A. Milner" <kamilner(a)superlative.org> Signed-off-by: Keith A. Milner <maillist(a)superlative.org> diff --git a/sound/usb/midi.c b/sound/usb/midi.c index b901f46..52b8c72 100644 --- a/sound/usb/midi.c +++ b/sound/usb/midi.c @@ -1860,9 +1860,14 @@ static void snd_usbmidi_switch_roland_altsetting(struct snd_usb_midi* umidi) hostif = &intf->altsetting[1]; intfd = get_iface_desc(hostif); + /* If either or both of the endpoints support interrupt transfer, + * then use the alternate setting + */ if (intfd->bNumEndpoints != 2 || - (get_endpoint(hostif, 0)->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) != USB_ENDPOINT_XFER_BULK || - (get_endpoint(hostif, 1)->bmAttributes & USB_ENDPOINT_XFERTYPE_MASK) != USB_ENDPOINT_XFER_INT) + !((get_endpoint(hostif, 0)->bmAttributes + & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT || + (get_endpoint(hostif, 1)->bmAttributes + & USB_ENDPOINT_XFERTYPE_MASK) == USB_ENDPOINT_XFER_INT)) return; snd_printdd(KERN_INFO "switching to altsetting %d with int ep\n", -- 1.9.1

2 1

[alsa-devel] [PATCH v2] ALSA: usb-audio: Fix max packet size calculation for USB audio
by Ricard Wanderlof 10 Oct '15

10 Oct '15

The addition of 0xffff ("almost 1" in Q16.16 format), resulting in the rounding up of the resulting value, was in the wrong place, as it is the resulting packet size that needs to be rounded up to the nearest integer (e.g. if the resulting packet size is calculated as 55.125 bytes, we need a packet of 56 bytes), rather than the rate value (ep->freqmax). Tested with an Edirol UA-5 both at 44.1 kHz and 96 kHz. Signed-off-by: Ricard Wanderlof <ricardw(a)axis.com> --- V2: Added tested device to commit message. No other changes. Since this clearly is a sensitive part of the code, here follows a lengthy rationale with examples to illustrate the problem. The code as it stands has the following expression on line 613 to calculate the maximum isochronous packet size: maxsize = ((ep->freqmax + 0xffff) * (frame_bits >> 3)) >> (16 - ep->datainterval); Here, ep->freqmax is the maximum assumed sample frequency, calculated from the nominal sample frequency plus 25%. It is ultimately derived from ep->freqn, which is in the units of samples per packet, from get_usb_full_speed_rate() or usb_high_speed_rate(), as applicable, in Q16.16 format. The expression essentially adds the Q16.16 equivalent of 0.999... (i.e. the largest number less than one) to the sample rate, in order to get a rate whose integer part is rounded up from the fractional value. The multiplication with (frame_bits >> 3) yields the number of bytes in a packet, and the (16 >> ep->datainterval) then converts it from Q16.16 back to an integer, taking into consideration the bDataInterval field of the endpoint descriptor, which describes how often isochronous packets are transmitted relative to the (micro)frame rate (125us or 1ms, for USB high speed and full speed, respectively). For this discussion we will assume a bDataInterval of 0, so the second line of the expression just converts the Q16.16 value to an integer. In order to illustrate the problem, we will set frame_bits 64, which corresponds to a frame size of 8 bytes. The problem here is that the addition of 0xffff is in the wrong place. We don't want the rounding up to take place on the frequency, but on the resulting packet size. Let's take an example. We have a sample rate of 96 kHz, so our ep->freqn is 786432 (see usb_high_speed_rate()). Add 25% (line 612) and we get 983040. The calculated maxsize is then ((983040 + 65535) * 8) >> 16 = 127 . However, if we do the number of bytes calculation in a less obscure way it's more apparent what the true corresponding packet size is: we get (96000 * 1.25 / 8000) * 8 = 120, where 1.25 is the 25% from line 612, and the 8000 is the number of isochronous packets per second on a high speed USB connection (125 us microframe interval). Rephrasing the maxsize expression to: maxsize = (ep->freqmax * (frame_bits >> 3) + 0xffff) >> (16 - ep->datainterval); we instead get (983040 * 8 + 65535) >> 16 = 120 which is the correct value. We can also do the calculation with a non-integer sample rate which is when rounding comes into effect: say we have 44.1 kHz (resulting ep->freqn = 361267, and resulting ep->freqmax 361267 * 1.25 = 451583 (rounded down). Original maxsize = ((451583 + 65535) * 8) << 16 = 63 (63.124.. rounded down) True maxsize = (44100 * 1.25 / 8000) * 8 = 55.125, i.e. 56 bytes required New maxsize = (451583 * 8 + 65535) >> 16 = 56 This is also corroborated by the wMaxPacketSize check on line 616. Assume that wMaxPacketSize = 108, with ep->maxpacksize then having the same value. As 108 < 127, we get maxsize = 108. ep->freqmax is then recalculated to (108 / 8) << 16 = 884736 . Putting that rate into the original maxsize calculation yields a maxsize of ((884736 + 65535) * 8) >> 16 = 115 (with decimals 115.99988). Clearly, we should get back the 108 here, which we would with the new expression: (884736 * 8 + 65535) >> 16 = 108 . As it currently stands, the error is tolerable because it only results in maxsize being a bit too big which wastes a couple of bytes, either as a result of the first maxsize calculation, or because the resulting calculation will hit the wMaxPacketSize value before the packet is too big, resulting in fixing the size to wMaxPacketSize even though the packet is actually not too long. However, I'm working on a quirk for a device which stuffs an extra four (non sample) bytes into each isochronous packet, and that means that the maxsize calculation must take this into account. During this work it became obvious that there was something wrong with the maxsize calculation, as the resulting packet size when wMaxPacketSize was hit did not correspond to the packet size which triggered the if statement to start with. Since this seems to me an obvious (after looking at it for a bit...) bug I'm submitting this as a separate patch rather than part of an upcoming patch series. sound/usb/endpoint.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/sound/usb/endpoint.c b/sound/usb/endpoint.c index e6f7189..be8a972 100644 --- a/sound/usb/endpoint.c +++ b/sound/usb/endpoint.c @@ -610,7 +610,7 @@ static int data_ep_set_params(struct snd_usb_endpoint *ep, /* assume max. frequency is 25% higher than nominal */ ep->freqmax = ep->freqn + (ep->freqn >> 2); - maxsize = ((ep->freqmax + 0xffff) * (frame_bits >> 3)) + maxsize = (ep->freqmax * (frame_bits >> 3) + 0xffff) >> (16 - ep->datainterval); /* but wMaxPacketSize might reduce this */ if (ep->maxpacksize && ep->maxpacksize < maxsize) { -- 1.7.10.4 -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30

2 4

[alsa-devel] How to download and install patch for ICS-43432 codec driver
by Ankhit Vivekananda 10 Oct '15

10 Oct '15

Hello, I am new to developing with ALSA. I have a situation where I need to use ICS-43432 MEMS microphone with a TMS320DM365 processor. I wanted to know if I could download the patch for ICS-43432 codec driver: http://permalink.gmane.org/gmane.linux.alsa.devel/143442. Appreciate any help. Thank you, Ankhit

2 1

[alsa-devel] Boss GT-001
by maillist＠superlative.org 10 Oct '15

10 Oct '15

I recently got access to a Boss GT-001. This is a small USB audio Interface for guitar with onboard FX which doesn't work with ALSA under Linux Mint 17 (running kernel 3.16.0-38-generic). I've not tried it with the latest ALSA development branch, but scanning the recent ALSA Dev archives, I can't see anything which might fix this. # lsusb ... Bus 001 Device 011: ID 0582:0187 Roland Corp (detailed lsusb output is towards the bottom of this email) The unit is moderately quirky compared to most audio devices. This unit includes on-board Boss guitar amp emulations and effects and the USB connection allows you to simultaneously record both the "wet" (with effects) and "dry" (without effects) signal. Thus the USB carries two separate stereo pairs to the computer. It also allows "re-amping" which allows you to apply effects to the output signal. The way this seems to do this is by having two separate stereo pair outputs from the computer one of which is processed via the onboard effects, and one of which is not. This is all just background, but the upshot of this is that the unit is a 2x stereo pair in, and 2x stereo pair out. However, this not only does not show up properly under Linux, but it will not play or record anything. ALSA sees it thusly: # aplay -l ... card 4: GT001 [GT-001], device 0: USB Audio [USB Audio] Subdevices: 0/1 Subdevice #0: subdevice #0 PLaying a CD-format file: # aplay hw:4 test.wav Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo aplay: set_params:1233: Sample format not available Available formats: - S32_LE # aplay hw:4 test.wav Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo No audio is output For input: # arecord -l card 4: GT001 [GT-001], device 0: USB Audio [USB Audio] Subdevices: 1/1 Subdevice #0: subdevice #0 The unit also supports MIDI which is used for both control of the unit itself via a PC editing application (editing settings, changing patches, etc.) and for simple DAW control. There are three USB MIDI ports for this which, on Windows, are labelled "GT-001", "GT-001 DAW CTRL" and "GT-001 CTRL" On Linux these show up as follows: # amidi -l IO hw:4,0,0 GT-001 MIDI 1 IO hw:4,0,1 GT-001 MIDI 2 IO hw:4,0,2 GT-001 MIDI 3 Any advice and pointers to get this working would be appreciated. Dmesg output: [17530.759008] usb 1-1: new high-speed USB device number 12 using ehci-pci [17530.893299] usb 1-1: New USB device found, idVendor=0582, idProduct=0187 [17530.893303] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [17530.893305] usb 1-1: Product: GT-001 [17530.893307] usb 1-1: Manufacturer: BOSS [17530.894412] snd-usb-audio: probe of 1-1:1.0 failed with error -5 [17530.927591] usb 1-1: Unable to change format on ep #8e: already in use [17530.927614] usb 1-1: Unable to change format on ep #8e: already in use [17530.927764] usb 1-1: Unable to change format on ep #8e: already in use [17530.927945] usb 1-1: Unable to change format on ep #8e: already in use [17530.928161] usb 1-1: Unable to change format on ep #8e: already in use [17530.928600] usb 1-1: Unable to change format on ep #8e: already in use [17530.928620] usb 1-1: Unable to change format on ep #8e: already in use [17530.928693] usb 1-1: Unable to change format on ep #8e: already in use [17530.928832] usb 1-1: Unable to change format on ep #8e: already in use [17530.928958] usb 1-1: Unable to change format on ep #8e: already in use [17530.929350] usb 1-1: Unable to change format on ep #8e: already in use [17530.929377] usb 1-1: Unable to change format on ep #8e: already in use [17530.929500] usb 1-1: Unable to change format on ep #8e: already in use [17530.929743] usb 1-1: Unable to change format on ep #8e: already in use [17530.929988] usb 1-1: Unable to change format on ep #8e: already in use [17530.930577] usb 1-1: Unable to change format on ep #8e: already in use [17530.930617] usb 1-1: Unable to change format on ep #8e: already in use [17530.930808] usb 1-1: Unable to change format on ep #8e: already in use [17530.931064] usb 1-1: Unable to change format on ep #8e: already in use [17530.931213] usb 1-1: Unable to change format on ep #8e: already in use [17531.330778] usb 1-1: Unable to change format on ep #8e: already in use [17531.334500] usb 1-1: Unable to change format on ep #8e: already in use lsusb output: lsusb -vv -d 0582:0187 Bus 001 Device 011: ID 0582:0187 Roland Corp. Couldn't open device, some information will be missing Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x0187 bcdDevice 0.00 iManufacturer 1 iProduct 2 iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 176 bNumInterfaces 4 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 255 Vendor Specific Subclass bInterfaceProtocol 0 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 04 04 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x0d EP 13 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0070 1x 112 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 04 04 18 01 44 ac 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x8e EP 14 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x0070 1x 112 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 03 03 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x84 EP 4 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 3 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 3 bInterfaceProtocol 0 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x03 EP 3 OUT bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x85 EP 5 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Cheers, Keith

4 19

[alsa-devel] [asoc:topic/rockchip 4/4] sound/soc/rockchip/rockchip_spdif.c:67:12: warning: 'rk_spdif_runtime_resume' defined but not used
by kbuild test robot 10 Oct '15

10 Oct '15

tree: https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git topic/rockchip head: f874b80e1571118fcf4554878633556f06f998e6 commit: f874b80e1571118fcf4554878633556f06f998e6 [4/4] ASoC: rockchip: Add rockchip SPDIF transceiver driver config: microblaze-allmodconfig (attached as .config) reproduce: wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/m… -O ~/bin/make.cross chmod +x ~/bin/make.cross git checkout f874b80e1571118fcf4554878633556f06f998e6 # save the attached .config to linux build tree make.cross ARCH=microblaze All warnings (new ones prefixed by >>): >> sound/soc/rockchip/rockchip_spdif.c:67:12: warning: 'rk_spdif_runtime_resume' defined but not used [-Wunused-function] static int rk_spdif_runtime_resume(struct device *dev) ^ vim +/rk_spdif_runtime_resume +67 sound/soc/rockchip/rockchip_spdif.c 51 { .compatible = "rockchip,rk3288-spdif", 52 .data = (void *) RK_SPDIF_RK3288 }, 53 {}, 54 }; 55 MODULE_DEVICE_TABLE(of, rk_spdif_match); 56 57 static int rk_spdif_runtime_suspend(struct device *dev) 58 { 59 struct rk_spdif_dev *spdif = dev_get_drvdata(dev); 60 61 clk_disable_unprepare(spdif->mclk); 62 clk_disable_unprepare(spdif->hclk); 63 64 return 0; 65 } 66 > 67 static int rk_spdif_runtime_resume(struct device *dev) 68 { 69 struct rk_spdif_dev *spdif = dev_get_drvdata(dev); 70 int ret; 71 72 ret = clk_prepare_enable(spdif->mclk); 73 if (ret) { 74 dev_err(spdif->dev, "mclk clock enable failed %d\n", ret); 75 return ret; --- 0-DAY kernel test infrastructure Open Source Technology Center https://lists.01.org/pipermail/kbuild-all Intel Corporation

1 0