jensverwiebe

Hi Uvrenight I'am not sure if you got my point with kernel versions of 5.11 or later. I did not emphasized the fakts enough, sorry. With those the sync finally works and thus makes ALSA operation ( JACK-less ) from within an DAW ( and also PulseAudio afaik ) working. It must be used duplex though, because the dummy endpoint stuff for line6 is not yet commited to any kernel tree afaik. This upcoming work will allow to use the playback or capture interfaces independently, which is interesting for device congregation. Aplay and arecord ( commandline ) cannot be used atm. for the same reason ( only activates playback OR capture side ). I also again ensured that your device is handled in format.c so we talk about the same driver in use: case USB_ID(0x0e41, 0x4247): /* Line6 Pod Go */ Here is an example of /proc/asound/HELIX/stream0 while operating in ARDOUR/MIXBUS as a pure ALSA-device ( duplex kernel 5.13 here ): LINE 6 HELIX at usb-0000:00:14.0-12, high speed : USB Audio Playback: Status: Running Interface = 2 Altset = 1 Packet Size = 224 Momentary freq = 48000 Hz (0x6.0000) Interface 2 Altset 1 Format: S32_LE Channels: 8 Endpoint: 0x03 (3 OUT) (ASYNC) Rates: 48000 Data packet interval: 125 us Bits: 24 Channel map: FL FR FC LFE RL RR FLC FRC Sync Endpoint: 0x83 (3 IN) Sync EP Interface: 3 Sync EP Altset: 1 Implicit Feedback Mode: Yes Capture: Status: Running Interface = 3 Altset = 1 Packet Size = 224 Momentary freq = 48000 Hz (0x6.0000) Interface 3 Altset 1 Format: S32_LE Channels: 8 Endpoint: 0x83 (3 IN) (ASYNC) Rates: 48000 Data packet interval: 125 us Bits: 24 Channel map: FL FR FC LFE RL RR FLC FRC You see, all is setup as it should be and is identically to the JACK approach i showed some posts earlier. Often people prefer the ALSA only operation ( ARDOUR devs recommend it even over JACK ), but i could think of situations, you may want to add congregated devices with zita_a2j or zita_j2a to enlarge your inputs/outputs. Be aware that the latter is maybe not always sampleaccurate. Just give a newer kernel a try ... Cheers ... Jens

Hi Uvrenight I just read up "POD Go supports the class compliant driver,which operates at 24-bit/48kHz sample rate." which is the same starting point as i had for the Helix LT. ( The modern Pod Go seems to be closer to Helix than the former Pod HD etc. ) My proposal is that you find your devices usb-id ( lsusb )and add it to the line6 devices that use a hardcoded 48kHz frequency. Recompile the module and reinsert as you can find it described in the thread somewhere earlier. This should give you the same basic usage like on driverless iOS or macOS use respective what we have for the Helix on linux atm.. ( kernel 5.11 or later for properly using implicit feedback endpoints btw. ) More info can be gathered with sudo lsusb -vvvv -d <your_vendor_id:your_device_id> if you like to investigate deeper. I myself would also like to be able to change the samplingfrequency for example. but i fear this is buried in vendorspecific classes, thus not reachable for us without further help from line6. Have fun ... Jens

First of all: any VM with USB-passthrough would do, but i found foxlet to be the easiest way to go while having the smallest footprint. Just follow https://github.com/foxlet/macOS-Simple-KVM

Bump - Just for linux heads-up: Linux Mint with 5.13 ( HWE ) kernel is still doing fine. Foxlet KVM serves me still well for HXEdit and did the hx 5.15 fw-update just perfect. Keep on rockin' on Linux ... Jens

Hi Folks I had a big surprise yesterday. As i always use HWE kernels on Linux Mint ( aka Ubuntu base ) i installed the now available 5.11 version and wanted to have a look if i can use implicit feedback by patching my device in the new implicit.c file special entries. To my surprise it worked OOTB ! Yay, no crude uneven samplerate or something, just staying stable and no xruns in hours ( tested down to 64 sample buffer in jack ). Along with my way to have HXEDIT in a small KVM all is nearly perfect now ( except staying fix @ 48KHz and you must use it always duplex ) EDIT: For the problem Helix only works duplex and thus as master i found a workaround. Use this script to add Helix in/outs to another master jackdevice which should also run @ 48kHz ( don't forget to make it runable with chmod +x ): #!/bin/bash gnome-terminal --title=Launch_HELIX_duplex -e '/bin/bash -c "zita-a2j -dhw:HELIX -j HELIX -c 8 | sleep 1 | zita-j2a -dhw:HELIX -j HELIX -c 8"' #If you have espeak and like this notification, uncomment next line #espeak "Enabling HELIX DUPLEX" sleep 3 #I recommend installing xdotool to get the terminal window out of the way. #Following command minimizes the window automatically xdotool getactivewindow windowminimize EDIT: Just talked with another Boss dev, who has the same problem and there will be a new way to start such devices in a way that allows also for solo capture or playback. This way zita_usb_in/out will be possible without the Helix being master. The code comes for kernel 5.13 and i guess we must test this and either try to apply to 5.13 too or in a later release. https://github.com/tiwai/sound/commit/ebe8dc5afb3912e2d4f5c62cf7c492a13143a77a Have fun and stay sane ... Cheers ... Jens Seeing is believing ( data ) : uname -a: 5.11.0-22-lowlatency #23~20.04.1-Ubuntu SMP PREEMPT Thu Jun 17 13:52:10 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux /proc/asound/HELIX/stream0: LINE 6 HELIX at usb-0000:06:00.0-2, high speed : USB Audio Playback: Status: Running Interface = 2 Altset = 1 Packet Size = 224 Momentary freq = 48000 Hz (0x6.0000) Interface 2 Altset 1 Format: S32_LE Channels: 8 Endpoint: 0x03 (3 OUT) (ASYNC) Rates: 48000 Data packet interval: 125 us Bits: 24 Channel map: FL FR FC LFE RL RR FLC FRC Sync Endpoint: 0x83 (3 IN) Sync EP Interface: 3 Sync EP Altset: 1 Implicit Feedback Mode: Yes Capture: Status: Running Interface = 3 Altset = 1 Packet Size = 224 Momentary freq = 48000 Hz (0x6.0000) Interface 3 Altset 1 Format: S32_LE Channels: 8 Endpoint: 0x83 (3 IN) (ASYNC) Rates: 48000 Data packet interval: 125 us Bits: 24 Channel map: FL FR FC LFE RL RR FLC FRC

Hi mates, some notes: - @torgeir, regarding nonfunctional rmmod in your script: i guess rmmod is just not default installed on your sys, use modprobe -r instead. - @ all: i' am able to get the endpoints working incl. the sync, by forcing it like for an Axe-FX3 for example. But the streams will not come up atm, grrrrrr. For all interested to fiddle until we get succes, here are my changes: In pcm.c i add something like this to the set_sync_ep_implicit_fb_quirk function ( your ID accordingly ) case USB_ID(0x0e41, 0x424a): /* Line6 HELIX LT */ ep = 0x83; ifnum = 3; goto add_sync_ep_from_ifnum; In endpoint.c Mike Oliphant found its needed to comment out in snd_usb_endpoint_start function. Otherwise the initialization of urbs would wait for each other ( capture/playback/sync ep ) forever. if (snd_usb_endpoint_implicit_feedback_sink(ep)) { for (i = 0; i < ep->nurbs; i++) { struct snd_urb_ctx *ctx = ep->urb + i; list_add_tail(&ctx->ready_list, &ep->ready_playback_urbs); } return 0; } Then one will get in terminal output while debugging ( trick: add "#define dev_dbg dev_info" to usb.h for avoiding a complete debug build of kernel ): jack/helix/duplex: dmesg | tail [11568.409129] usb 9-1.3: Setting params for ep #83 (type 0, 12 urbs), ret=0 [11568.409655] usb 9-1.3: setting usb interface 2:1 [11568.409656] usb 9-1.3: Creating new playback data endpoint #3 [11568.409659] usb 9-1.3: Re-using EP 83 in iface 3,1 @000000005f5f3a5c [11568.410006] usb 9-1.3: Setting params for ep #3 (type 0, 12 urbs), ret=0 [11568.410007] usb 9-1.3: match_endpoint_audioformats: (fmt @00000000f60f1dd9) score 2 [11568.410014] usb 9-1.3: Setting params for ep #83 (type 0, 12 urbs), ret=0 [11568.410015] usb 9-1.3: Starting data EP @00000000ef58d6e2 [11568.410478] usb 9-1.3: Starting sync EP @000000005f5f3a5c [11568.410960] usb 9-1.3: Starting data EP @000000005f5f3a5c jack/helix/playback:~$ dmesg | tail [11592.501593] usb 9-1.3: setting usb interface 2:1 [11592.501596] usb 9-1.3: Re-using EP 3 in iface 2,1 @00000000ef58d6e2 [11592.501598] usb 9-1.3: Re-using EP 83 in iface 3,1 @000000005f5f3a5c [11592.501924] usb 9-1.3: Setting params for ep #3 (type 0, 12 urbs), ret=0 [11592.501926] usb 9-1.3: match_endpoint_audioformats: (fmt @00000000f60f1dd9) score 2 [11592.501936] usb 9-1.3: Setting params for ep #83 (type 0, 12 urbs), ret=0 [11592.501937] usb 9-1.3: Starting data EP @00000000ef58d6e2 [11592.502393] usb 9-1.3: Starting sync EP @000000005f5f3a5c jack/helix/capture: dmesg | tail [11611.315495] usb 9-1.3: Re-using EP 83 in iface 3,1 @000000005f5f3a5c [11611.315781] usb 9-1.3: Setting params for ep #83 (type 0, 12 urbs), ret=0 [11611.316087] usb 9-1.3: Starting data EP @000000005f5f3a5c This all looks exact how it should be and like a Boss Katana for example will show up, but the helix will not yet come to life. Ideas are welcome. As i think we all have a lot time for such experimenting now, we may come to an result asap i hope. Cheers ... Jens

Hi Sorry for being late to the party ;) Nice you sorted things out for now. Be aware that the new device id's are already in 5.5 kernel, so if you use the HWE you should be fine. 2020-01-25 15:09:17 - ALSA: usb-audio: add quirks for Line6 Helix devices fw>=2.82 Here we added: + case USB_ID(0x0E41, 0x4248): /* Line6 Helix >= fw 2.82 */ + case USB_ID(0x0E41, 0x4249): /* Line6 Helix Rack >= fw 2.82 */ + case USB_ID(0x0E41, 0x424a): /* Line6 Helix LT >= fw 2.82 */ Thus your adaptions are only needed for older kernel ( < 5.5 ) or if you need my additional frequency trick in case you suffer from rare clicks. I got a bit further with this sync problem, but still do not get this 100% working. As is should do for now. Cheers ... Jens

Just FYI: Since i made the 2.82 firmware update, my Helix LT identifies with device id 0x424a ( idProduct=424a ) . Aka the patches must be adapted to work again. Not sure how other Helix devices changed because of the new ( unified ? ) core architecture. Did not yet noticed any further benfit other than new sounds/stomps etc. Sidenote: I don't wanna have Helix shown up in the systems pulse audio because it would not work reliable there either. So i made an udev rule to ignore it. If someone else cares too, place into /etc/udev/rules.d/89-pulseaudio.rules: #Ignore Helix ATTRS{idVendor}=="0e41", ATTRS{idProduct}=="424a", ENV{PULSE_IGNORE}="1" Cheers ... Jens

Hi Johan 1.The error is not distro agnostic but a kernel/alsa thing. 2.To me it looks you are compiling from the wrong directory. Make sure to stay inside the gotten sourcedir usb dir. In your case it should be cd /home/johan/kernelbuild/linux-5.1.15/sound/usb Or: Get this patch and scriptset from me: www.jensverwiebe.de/Other/audio_patching.tar.xz Unpack into your kernel-src, run script right from that dir ( all explained in the README ). Btw: Someone took my patch and commited it partly to alsa, so it might show up upstream anytime soon. Jens

Hi Rodney, you got pm. As you use another kernel as me we must first sort out what fails, perhaps the suggestions i made already helped you. If so just edit the linked script/patch package accordingly and all should go well. If not pls leave a log here so i can judge the problem. I'am sure its just due the where modules/devices added in between. Jens

I made this just for safety, in case you have a specialized bootconfig in the active kernel. Such can be using hardwaretimers or other relevant settings in alsa. It makes sure the snd_usb is configured same as your active kernel. EDIT: just saw: echo "Compiling with echo $MAKEOPTS threads" should read echo "Compiling with $MAKEOPTS threads" Late night cp/paster error, but not functional relevant. Jens

@ Shemeshg I pm'ed you a bashscript to automate the patching/compiling/modulereplace. All patches and the modified makefile is included. Just unpack in kernel sourcedir and run. Pls test. Unfortunately i still could not catch an expert on the usbrate thingie, so as long as we must patch this is more convenient at least. Only you must get the desired kernel src still,, i tested with 4.4.119 ( wget -c https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.119.tar.gz ) Cheers ... Jens

Hi Shemeshg Perhaps i was not clear enough. If you change the kernel (-headers), you have always to recompile the module else you break the dependencies. KVERSION = $(shell uname -r) assures you link to the active one. You may have just copied the former compiled snd_usb_audio to 4.4.116, this will not work. Syslog with `tail -f` notificatien implies this. What can work is using a newer or older linux/sound/usb as long as you compile it against KVERSION. This may give you an advantage in fixed components, but also may break some other if it also depends on other sound changes. So staying in the 4.4.xxx is a bit safer. I tested up to 4.10.xxx will work also, but does not give benefits for helix. ( but for the other line6 drivers ) Matching the source to KVERSION is indeed the best option, as you get backported stuff/fixes too. Hope this clarifies it .... Jens

Initially you would not need to get a new kernel source, if snd_usb did not change. If in doubt, check the changelog. The makefile i posted always uses : KVERSION = $(shell uname -r) aka uses the headers of the active kernel. So just recompile that part. If you absolutely need to renew all: Actual: https://www.kernel.org/pub/linux/kernel/v4.x/linux-4.4.116.tar.gz The kernels are always to find in : https://www.kernel.org/pub/linux/kernel/v4.x/ Or you clone the main repo ( git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git ) and checkout the wished tag and patch it. ( you can also cherrypick sound/usb ) Compile snd_usb_audio like described formerly. Full kernel: Don't forget to check its setup before compile, i use: cp /boot/config-`uname -r` .config make oldconfig make menuconfig Set lowlatency + timers to 1000Hz + HW timers used ( will be active if the former config was configured like this already ) Then compile typically with: make -j `nproc` LOCALVERSION= deb-pkg Jens

Great you made it :) Yep, avoiding analog wiring is a big quality win. As well is the working midi, which allows you to use the miditemo depending delay timings + patch changes etc.. Just prepare an "all time patch", we need not to change kernels such often ( i hope, ask Intel :P) ) If you like you can post your experience in the alsa mailing lists too. More users rise the interest for developing a full implementation. Sidenote: using pulse-jacksink can disturb jack freewheeling which is for example used by Ardour (stem-) export. If you experience oddness, just deactivate for this usecase. ( pactl unload-module module-jack-sink / pactl load-module module-jack-sink channels=2 ), i use prepared scripts for load/unload in the linux mint cinnamon scripts applet ) Cheers ... Jens