On Wed, Jul 20, 2011 at 9:40 AM, Nicolai Krakowiak
wrote:
> On Sun, Jul 17, 2011 at 4:37 AM, Daniel Mack wrote:
>> Interface 3 is the MIDI streaming interface, and
>> snd_usb_create_mixer() shouldn't find any controls there. I assume
>> there is a confusion in the usage of mixer->chip_ctrl_if, an
On Sun, Jul 17, 2011 at 4:37 AM, Daniel Mack wrote:
> Interface 3 is the MIDI streaming interface, and
> snd_usb_create_mixer() shouldn't find any controls there. I assume
> there is a confusion in the usage of mixer->chip_ctrl_if, and the code
> there also seems wrong. Can you test whether the at
On Sat, Jul 16, 2011 at 10:23 AM, Nicolai Krakowiak
wrote:
> On Wed, Jul 13, 2011 at 5:27 AM, Daniel Mack wrote:
>> Can you check the value of the "ctrlif" argument in snd_usb_create_mixer()?
>
> Two instances: ctrlif = 0, ctrlif = 3. Here's the relevant kernel
> log snippet:
Interface 3 is t
On Wed, Jul 13, 2011 at 5:27 AM, Daniel Mack wrote:
> Can you check the value of the "ctrlif" argument in snd_usb_create_mixer()?
Two instances: ctrlif = 0, ctrlif = 3. Here's the relevant kernel
log snippet:
[ 428.011513] ALSA sound/usb/endpoint.c:434: 3:1:1: add audio endpoint 0x1
[ 428.4
On Wed, Jul 13, 2011 at 7:03 AM, Daniel Mack wrote:
> Even though the root cause for your problem here is somewhere else, we
> indeed should prevent dividing by zero. Can you send the a new patch
> with only the first hunk of your "hack" (the one that checks for csize
> == 0) again with your Signe
On Wed, Jul 13, 2011 at 10:07 AM, Nicolai Krakowiak
wrote:
> If I apply the trivial hacky workaround (attached), I can play sound
> out the device again. Here's the initialization output with the
> bControlSize hack applied.
Even though the root cause for your problem here is somewhere else, we
On Wed, Jul 13, 2011 at 10:07 AM, Nicolai Krakowiak
wrote:
> There seems to be an issue in continuing along in mixer.c. I
> sprinkled printfs as I'm bad at parsing the kernel trace. It looks
> like the following occurs:
>
> parse_audio_unit() with a subtype == UAC_FEATURE_UNIT
> parse_audio_feat
On Tue, Jul 12, 2011 at 5:22 PM, Daniel Mack wrote:
> On Tue, Jul 12, 2011 at 12:39 PM, Nicolai Krakowiak
> wrote:
>> On Mon, Jul 11, 2011 at 3:22 AM, Daniel Mack wrote:
>> I got as far as sound/usb/card.c:514 calling snd_usb_create_mixer().
>> It looks like it is hitting the default clause in c
On Tue, Jul 12, 2011 at 3:48 AM, Daniel Mack wrote:
> As you seem to known what you're doing, can you try to disable the
> mixer creation entirely? Just bail out very early in
> snd_usb_create_mixer() or don't call it at all in the first place. The
> audio should stream without any mixer functions
On Tue, Jul 12, 2011 at 12:39 PM, Nicolai Krakowiak
wrote:
> On Mon, Jul 11, 2011 at 3:22 AM, Daniel Mack wrote:
> I got as far as sound/usb/card.c:514 calling snd_usb_create_mixer().
> It looks like it is hitting the default clause in check_input_term()
> and returning -ENODEV. Another missing
Nicolai Krakowiak wrote:
> On Mon, Jul 11, 2011 at 3:22 AM, Daniel Mack wrote:
> > Ok, that is also what your lsusb dump shows - the FORMAT_TYPE
> > descriptor has a length of 10, even though a FORMAT_TYPE_I descriptor
> > must be 6 bytes longs, according to the UAC specification. I can't see
> >
On Tue, Jul 12, 2011 at 12:39 PM, Nicolai Krakowiak
wrote:
> On Mon, Jul 11, 2011 at 3:22 AM, Daniel Mack wrote:
>> So we could just simply ignore this fact. Can you try what happens
>> when you change the check in endpoint.c (around line 355, where the
>> patch also changed things) so that it re
On Mon, Jul 11, 2011 at 3:22 AM, Daniel Mack wrote:
> Ok, that is also what your lsusb dump shows - the FORMAT_TYPE
> descriptor has a length of 10, even though a FORMAT_TYPE_I descriptor
> must be 6 bytes longs, according to the UAC specification. I can't see
> a reason why it is 10 bytes longs,
On Sat, Jul 9, 2011 at 6:49 PM, Nicolai Krakowiak
wrote:
> On Sat, Jul 9, 2011 at 2:25 AM, Daniel Mack wrote:
>> Can you apply the attached patch and send us a the kernel log messages again?
>
> After power cycling the device after boot:
>
> [ 191.372814] 10:1:1 : invalid UAC_FORMAT_TYPE desc (pr
On Sat, Jul 9, 2011 at 2:25 AM, Daniel Mack wrote:
> Can you apply the attached patch and send us a the kernel log messages again?
After power cycling the device after boot:
[ 191.372814] 10:1:1 : invalid UAC_FORMAT_TYPE desc (protocol 32, bLength 10)
[ 191.372935] 10:2:1 : invalid UAC_FORMAT_
On Fri, Jul 8, 2011 at 2:27 AM, Daniel Mack wrote:
> Can I ask you to download the newest
> versions of the usbutils source code and try it out? You can find them
> here: http://git.kernel.org/?p=linux/kernel/git/gregkh/usbutils.git;a=summary
Done and attached.
> Also, support for this protocol
On Wed, Jul 6, 2011 at 6:08 AM, Graham Dicker wrote:
> Try making the Focusrite the primary device. This worked for me under
> somewhat similar circumstances.
>
> Graham Dicker
Thanks for the suggestion, Graham. I tried this last night without
success unfortunately.
nicolai
--
Nicolai Krakowiak wrote:
> I have an unsupported USB device (Focusrite Scarlett 18i6), and I was
> curious what steps are necessary to get it to work under Linux.
> [158184.220019] usb 1-8: new high speed USB device using ehci_hcd and
> address 20
> [158184.372587] 20:1:1 : invalid UAC_FORMAT_T
Nicolai Krakowiak wrote:
> Hi folks,
>
> I have an unsupported USB device (Focusrite Scarlett 18i6), and I was
> curious what steps are necessary to get it to work under Linux.
> The internal sound card on this machine works well (hw:0). After
> loading snd_usb_audio, the 18i6 shows up as expect
Hi folks,
I have an unsupported USB device (Focusrite Scarlett 18i6), and I was
curious what steps are necessary to get it to work under Linux.
The internal sound card on this machine works well (hw:0). After
loading snd_usb_audio, the 18i6 shows up as expected as device 1:
% cat /proc/asound/c
20 matches
Mail list logo
