Would any part of this project help with the TC Helicon Blender?

[heeen]

I have a TC Helicon blender and it does not work if it is powered on while attached to linux. If I plug it into a windows machine, power it on and then move it to my linux machine, it works fine.

With does not work I mean that it shows up as audio device with all channels, but reading from it times out.

I suspect that the manufacturer reuses hardware for products with similar features and was wondering if anything was known already? Like has the goxlr shown similar behaviour as described above?

[heeen]

FWIW I am on ubuntu 22.10 5.19.0-1015-lowlatency #16-Ubuntu SMP PREEMPT_DYNAMIC

[heeen]

follow up question: is the initializer tool doing the same as applying the DKMS patch? or would you need both?

[FrostyCoolSlug]

The initialiser tool sends the commands to activate audio channels (the utility has this baked in) on the GoXLR, so it might work in this case assuming they have similar initialisation profiles.

[FrostyCoolSlug]

If not, if you can grab a USB pcap of plugging in the Blender on Windows, I can check if it's easily transplantable to Linux.

[heeen]

I added the blender device id, but it says the device is already initialized. I captured plug in usb events on windows and linux and windows and noticed that windows has some URB Function: URB_FUNCTION_SYNC_RESET_PIPE_AND_CLEAR_STALL (0x001e) events that I didn't see on the linux side.

[FrostyCoolSlug]

Could you provide the full pcap please?

[heeen]

blender.zip

[FrostyCoolSlug]

Thanks, I'm not at a computer currently, but will check as soon as I am (might be a day or two, I'm on vacation currently :).

In the meantime, if you'd like to experiment, you can try removing the if Err(Pipe) condition from the initialiser to force an initialisation attempt.

Before initialising the code currently does a GoXLR specific check for initialisation, which is seemingly always succeeding on the Blender, so it's not running the code that attempts to activate the audio

[heeen]

the result is now that the front stream/device (?) is missing. arecord -L has these:

sysdefault:CARD=Blender
usbstream:CARD=Blender

recording from them does not work:

arecord -D sysdefault:CARD=Blender  -r48000 -fS32_LE -c 12 blender.wav -d 20
ALSA lib pcm_dsnoop.c:566:(snd_pcm_dsnoop_open) unable to open slave
arecord: main:831: audio open error: No such file or directory

[FrostyCoolSlug]

Just to make life easier, I've made a blender-test branch with all the GoXLR code specifically removed from the initialiser, and forced initialisation.

Can you give that a try and see if it'll activate the audio?

Note, this branch was made on mobile, but hopefully will work :)

[FrostyCoolSlug]

Do the other channels work correctly?

[heeen]

re-plugging the device brings the other streams back:

arecord -L | grep Blend
hw:CARD=Blender,DEV=0
    Blender, USB Audio
plughw:CARD=Blender,DEV=0
    Blender, USB Audio
sysdefault:CARD=Blender
    Blender, USB Audio
front:CARD=Blender,DEV=0
    Blender, USB Audio
dsnoop:CARD=Blender,DEV=0
    Blender, USB Audio
usbstream:CARD=Blender
    Blender

and recording works now:

arecord -D sysdefault:CARD=Blender  -r48000 -fS32_LE -c 12 blender.wav -d 20
Recording WAVE 'blender.wav' : Signed 32 bit Little Endian, Rate 48000 Hz, Channels 12
ls blender.wav -l
-rw-r--r-- 1 florian florian 46080044 Feb 13 16:53 blender.wav

[heeen]

can you explain what the initialiser does? maybe it has to run as early as possible via udev? I just run it by hand right now

[FrostyCoolSlug]

The initialiser detaches the device from alsa, claims the main interface, sends a control packet to the device which activates the audio channels at 48000hz, then does a soft reset of the device to hand control back to alsa (which should pick it back up).

In the pcap it'll likely be the first control write to the device. I'm guessing the blender one is slightly different from the GoXLR one.

EDIT: at least for the GoXLR, it doesn't matter when it's sent, so long as the udev permissions are set up

[heeen]

so the packet seems to do the right thing, but when re-attaching something seems to be missing it seems

[FrostyCoolSlug]

In the context of the GoXLR, it'll also do the appropriate read to allow sending of URBs to the vendor configuration interface. I've removed that check from the blender-test branch

[FrostyCoolSlug]

Might be worth taking a look at dmesg, just to see if the device is doing something when resetting which could be resolved.. if the initialiser works but just needs a replug, then a reset isn't happening correctly.

[heeen]

# power-cycling Blender
[1760664.433815] usb 5-4: USB disconnect, device number 21
[1760668.994526] usb 5-4: new high-speed USB device number 22 using xhci_hcd
[1760669.122989] usb 5-4: New USB device found, idVendor=1220, idProduct=8fe1, bcdDevice= 1.28
[1760669.122997] usb 5-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1760669.123000] usb 5-4: Product: Blender
[1760669.123002] usb 5-4: Manufacturer: TC-Helicon
[1760669.123005] usb 5-4: SerialNumber: 10400041
[1760669.175703] usb 5-4: clock source 41 is not valid, cannot use

# running initializer
[1760687.398358] usb 5-4: usbfs: interface 0 claimed by snd-usb-audio while 'goxlr-initialis' sets config #1
[1760687.399822] usb 5-4: USB device is in the shutdown state, cannot create a card instance
[1760687.399830] snd-usb-audio: probe of 5-4:1.0 failed with error -5
[1760687.526691] usb 5-4: reset high-speed USB device number 22 using xhci_hcd

#hot-plugging Blender
[1760700.776442] usb 5-4: USB disconnect, device number 22
[1760705.401517] usb 5-4: new high-speed USB device number 23 using xhci_hcd
[1760705.530060] usb 5-4: New USB device found, idVendor=1220, idProduct=8fe1, bcdDevice= 1.28
[1760705.530068] usb 5-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1760705.530071] usb 5-4: Product: Blender
[1760705.530073] usb 5-4: Manufacturer: TC-Helicon
[1760705.530075] usb 5-4: SerialNumber: 10400041

[FrostyCoolSlug]

Thanks, that's making some sense.. as an experiment, could you remove the lines for handle.release_interface, it looks like the release is waking alsa up, then the reset immediately after is causing the problems.

[heeen]

[1762101.292455] usb 5-4: new high-speed USB device number 24 using xhci_hcd
[1762101.420006] usb 5-4: New USB device found, idVendor=1220, idProduct=8fe1, bcdDevice= 1.28
[1762101.420014] usb 5-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1762101.420017] usb 5-4: Product: Blender
[1762101.420020] usb 5-4: Manufacturer: TC-Helicon
[1762101.420022] usb 5-4: SerialNumber: 10400041
[1762101.480134] usb 5-4: clock source 41 is not valid, cannot use
[1762113.657852] usb 5-4: usbfs: interface 0 claimed by snd-usb-audio while 'goxlr-initialis' sets config #1
[1762113.659363] usb 5-4: USB device is in the shutdown state, cannot create a card instance
[1762113.659369] snd-usb-audio: probe of 5-4:1.0 failed with error -5
[1762113.783095] usb 5-4: reset high-speed USB device number 24 using xhci_hcd

[heeen]

wouldn't it be better to coax the usb driver do this on plug-in? using some quirks flag or config or even a patch?

[FrostyCoolSlug]

It's definitely something I've been considering more recently, a kernel patch to the usb sound system is very doable (there are other devices that have them, the mbox2 is incredibly similar), it's primarily a time and effort thing though, obviously the GoXLR works correctly with this code, so the Blender not is somewhat of an out-of-scope case. With that being said, seeing as they both appear to have a shared initialisation sequence, it might be more useful now just for device support

[FrostyCoolSlug]

One of the things that has made pushing this to the kernel more difficult, however, is that for the GoXLR there are two parts to the initialisation. The first, as with the Blender is audio activation, which can be in the kernel, the second is the vendor specific configuration interface setup, which arguably shouldn't. While it's related to the device, it's strictly speaking not related to audio (it's also useless by itself without the utility). Even if the GoXLR audio setup was available in the kernel, most of the device would still be unusable without the util, which would have to continue doing the 'initialisation' phase, which is unfortunately where everything diverges slightly.

With that being said, when I get home from vacation, I'll do some double checking on the initialiser, and review the pcap to see if I can get you something at least interim to get audio working nicely. There have been a few changes to how the utility handles initialisation which may not have been ported back to the initialiser