[alsa-devel] Line6 Helix - usb compliant but not working correct
Hi folks
I recently got a Line6 Helix LT which can work usb compliant for example on
OSX or IOS. No driver is needed but the samplerate is fixed to 48000 ( which is okay for the first ).
Now i expected this device to work ootb in alsa, which turned out to be half the truth.
Connecting the device threw " usb 7-2: parse_audio_format_rates_v2(): unable to retrieve number of sample rates (clock 16)"
so i investigated a bit and found this workaround:
--- "/media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/clock (Kopie).c" 2017-11-08 10:06:31.000000000 +0100 +++ /media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/clock.c 2017-11-14 23:06:51.750924051 +0100 @@ -361,6 +361,13 @@ static int set_sample_rate_v2(struct snd struct uac_clock_source_descriptor *cs_desc;
clock = snd_usb_clock_find_source(chip, fmt->clock, true); + /* + * Line6 HELIX does not respond to sample rate + * set requests. The only valid rate is 48000. + */ + if (chip->usb_id == USB_ID(0x0e41, 0x4244) && rate == 48000) + return 0; + if (clock < 0) return clock;
--- "/media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/format (Kopie).c" 2017-11-08 10:06:31.000000000 +0100 +++ /media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/format.c 2017-11-14 23:12:24.329766243 +0100 @@ -293,6 +293,20 @@ static int parse_audio_format_rates_v2(s int nr_triplets, data_size, ret = 0; int clock = snd_usb_clock_find_source(chip, fp->clock, false);
+ /* + * Line6 HELIX does not respond to sample rate + * query requests. The only valid rate is 48000. + */ + if (chip->usb_id == USB_ID(0x0e41, 0x4244)) { + fp->nr_rates = 1; + fp->rate_min = 48000; + fp->rate_max = 48000; + fp->rates = SNDRV_PCM_RATE_48000; + fp->rate_table = kmalloc(sizeof(int), GFP_KERNEL); + fp->rate_table[0] = 48000; + return 0; + } + if (clock < 0) { dev_err(&dev->dev, "%s(): unable to find clock source (clock %d)\n",
This trick made the device appear in aplay -l and /proc/asound just as expected.
[ 7988.495085] usb 7-2: new high-speed USB device number 4 using xhci_hcd [ 7988.663622] usb 7-2: New USB device found, idVendor=0e41, idProduct=4244 [ 7988.663625] usb 7-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 7988.663627] usb 7-2: Product: HELIX [ 7988.663629] usb 7-2: Manufacturer: LINE 6 [ 7988.663630] usb 7-2: SerialNumber: 2744535
But i ended up with sometimes occuring soft clicks in playback which imply i have timing problems.
Another symptom is aplay does not output any sound while not throwing any error while in jack i can create the driver just fine.
I would apreciate any hint what i could try out here.
Greetings from Hamburg ... Jens
On 29/11/17 13:26, Jens Verwiebe wrote:
Hi folks
I recently got a Line6 Helix LT which can work usb compliant for example on
Interesting. I would like to try the Helix in Linux too. I have seen similar issues when fiddling with set_sample_rate. Some comments/ideas below.
OSX or IOS. No driver is needed but the samplerate is fixed to 48000 ( which is okay for the first ).
Now i expected this device to work ootb in alsa, which turned out to be half the truth.
Connecting the device threw " usb 7-2: parse_audio_format_rates_v2(): unable to retrieve number of sample rates (clock 16)"
so i investigated a bit and found this workaround:
"/media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/clock (Kopie).c" 2017-11-08 10:06:31.000000000 +0100 +++ /media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/clock.c 2017-11-14 23:06:51.750924051 +0100 @@ -361,6 +361,13 @@ static int set_sample_rate_v2(struct snd struct uac_clock_source_descriptor *cs_desc;
clock = snd_usb_clock_find_source(chip, fmt->clock, true); + /* + * Line6 HELIX does not respond to sample rate + * set requests. The only valid rate is 48000. + */ + if (chip->usb_id == USB_ID(0x0e41, 0x4244) && rate == 48000) + return 0;
if (clock < 0) return clock;
"/media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/format (Kopie).c" 2017-11-08 10:06:31.000000000 +0100 +++ /media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/format.c 2017-11-14 23:12:24.329766243 +0100 @@ -293,6 +293,20 @@ static int parse_audio_format_rates_v2(s int nr_triplets, data_size, ret = 0; int clock = snd_usb_clock_find_source(chip, fp->clock, false);
+ /* + * Line6 HELIX does not respond to sample rate + * query requests. The only valid rate is 48000. + */ + if (chip->usb_id == USB_ID(0x0e41, 0x4244)) { + fp->nr_rates = 1; + fp->rate_min = 48000; + fp->rate_max = 48000; + fp->rates = SNDRV_PCM_RATE_48000; + fp->rate_table = kmalloc(sizeof(int), GFP_KERNEL); + fp->rate_table[0] = 48000; + return 0; + }
if (clock < 0) { dev_err(&dev->dev, "%s(): unable to find clock source (clock %d)\n",
This trick made the device appear in aplay -l and /proc/asound just as expected.
[ 7988.495085] usb 7-2: new high-speed USB device number 4 using xhci_hcd [ 7988.663622] usb 7-2: New USB device found, idVendor=0e41, idProduct=4244 [ 7988.663625] usb 7-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 7988.663627] usb 7-2: Product: HELIX [ 7988.663629] usb 7-2: Manufacturer: LINE 6 [ 7988.663630] usb 7-2: SerialNumber: 2744535
But i ended up with sometimes occuring soft clicks in playback which imply i have timing problems.
Another symptom is aplay does not output any sound while not throwing any error while in jack i can create the driver just fine.
Have you tried debugging the pointer position with that device? Do you get sensible buffer sizes with `-v` in aplay for 48KHz, 24 bits, etc?
I once ended up with really small buffers when I changed the usb audioformats for a fixed rate device so there was not sound whatsoever even though all the devices were present. I am not sure whether fp->rates should get SNDRV_PCM_RATE_CONTINUOUS either way and then min/max = 48KHz delimiting it.
Jorge.
I would apreciate any hint what i could try out here.
Greetings from Hamburg ... Jens
Hi,, yeah thx for looking into it.
TBH i tried all kinda stuff already and also am able to compare all logs with a Focusrite Scarlett 6i6, which shows
almost exactly same outputs but works just fine. This makes me clueless.
I also investigated if this could be a firmware bug, but then it would not work on osx either, no ?
Something new i found: if i capture from helix and play this file with scarlett all is fine. So it seems to be something with out-of-sync playback only.
Am 29.11.2017 um 15:51 schrieb Jorge:
On 29/11/17 13:26, Jens Verwiebe wrote:
Hi folks
I recently got a Line6 Helix LT which can work usb compliant for example on
Interesting. I would like to try the Helix in Linux too. I have seen similar issues when fiddling with set_sample_rate. Some comments/ideas below.
OSX or IOS. No driver is needed but the samplerate is fixed to 48000 ( which is okay for the first ).
Now i expected this device to work ootb in alsa, which turned out to be half the truth.
Connecting the device threw " usb 7-2: parse_audio_format_rates_v2(): unable to retrieve number of sample rates (clock 16)"
so i investigated a bit and found this workaround:
"/media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/clock (Kopie).c" 2017-11-08 10:06:31.000000000 +0100 +++ /media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/clock.c 2017-11-14 23:06:51.750924051 +0100 @@ -361,6 +361,13 @@ static int set_sample_rate_v2(struct snd struct uac_clock_source_descriptor *cs_desc;
clock = snd_usb_clock_find_source(chip, fmt->clock, true); + /* + * Line6 HELIX does not respond to sample rate + * set requests. The only valid rate is 48000. + */ + if (chip->usb_id == USB_ID(0x0e41, 0x4244) && rate == 48000) + return 0;
if (clock < 0) return clock;
"/media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/format (Kopie).c" 2017-11-08 10:06:31.000000000 +0100 +++ /media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/format.c 2017-11-14 23:12:24.329766243 +0100 @@ -293,6 +293,20 @@ static int parse_audio_format_rates_v2(s int nr_triplets, data_size, ret = 0; int clock = snd_usb_clock_find_source(chip, fp->clock, false);
+ /* + * Line6 HELIX does not respond to sample rate + * query requests. The only valid rate is 48000. + */ + if (chip->usb_id == USB_ID(0x0e41, 0x4244)) { + fp->nr_rates = 1; + fp->rate_min = 48000; + fp->rate_max = 48000; + fp->rates = SNDRV_PCM_RATE_48000; + fp->rate_table = kmalloc(sizeof(int), GFP_KERNEL); + fp->rate_table[0] = 48000; + return 0; + }
if (clock < 0) { dev_err(&dev->dev, "%s(): unable to find clock source (clock %d)\n",
This trick made the device appear in aplay -l and /proc/asound just as expected.
[ 7988.495085] usb 7-2: new high-speed USB device number 4 using xhci_hcd [ 7988.663622] usb 7-2: New USB device found, idVendor=0e41, idProduct=4244 [ 7988.663625] usb 7-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 7988.663627] usb 7-2: Product: HELIX [ 7988.663629] usb 7-2: Manufacturer: LINE 6 [ 7988.663630] usb 7-2: SerialNumber: 2744535
But i ended up with sometimes occuring soft clicks in playback which imply i have timing problems.
Another symptom is aplay does not output any sound while not throwing any error while in jack i can create the driver just fine.
Have you tried debugging the pointer position with that device? Do you get sensible buffer sizes with `-v` in aplay for 48KHz, 24 bits, etc?
I get just this but silence ( while plughhw:1,0 == scarlett looks same and plays sound ):
aplay -D plughw:6,0 -vv test.wav Wiedergabe: WAVE 'test.wav' : Signed 16 bit Little Endian, Rate: 44100 Hz, stereo Plug PCM: Rate conversion PCM (48000, sformat=S16_LE) Converter: libspeex (builtin) Protocol version: 10002 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5512 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 5512 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 6206523236469964800 Slave: Route conversion PCM (sformat=S32_LE) Transformation table: 0 <- 0 1 <- 1 2 <- none 3 <- none 4 <- none 5 <- none 6 <- none 7 <- none Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24001 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 24000 stop_threshold : 24001 silence_threshold: 0 silence_size : 0 boundary : 6755680916032454656 Slave: Hardware PCM card 6 'HELIX' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 8 rate : 48000 exact rate : 48000 (48000/1) msbits : 32 buffer_size : 24001 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 24000 stop_threshold : 24001 silence_threshold: 0 silence_size : 0 boundary : 6755680916032454656 appl_ptr : 0 hw_ptr : 0
I once ended up with really small buffers when I changed the usb audioformats for a fixed rate device so there was not sound whatsoever even though all the devices were present. I am not sure whether fp->rates should get SNDRV_PCM_RATE_CONTINUOUS either way and then min/max = 48KHz delimiting it.
Tried this already, makes no difference.
Jorge.
I would apreciate any hint what i could try out here.
Greetings from Hamburg ... Jens
My wisdom is at the end here ... Jens ;-)
Hi, me again
In between i got the line6 helix working fine with a hack, which is to set an arbitray rate i have readout from another interface on the same bus. This works reliable so far, no more clicks, no xruns over several hours. There must be som magic to get the true usbrate from this device, but i did no fond a way yet, so my hack is more something unique for my working situation.
I also tried to get the implicite feeback from the capture interface to the pb interface to get a proper sync_ep, but still the rate is plain stiff.
Another problem is the mixer, which should be a plain passthrough. Cause ctrl interface is somewhat broken pure alsa does not work, but jack can create the device just fine.
I attach below the lsusb dump from the helix + my hack and the resulting working proc for further investigation.
Any ideas and voodoo is welcome.
Cheers ... Jens
Am 29.11.2017 um 16:24 schrieb Jens Verwiebe:
Hi,, yeah thx for looking into it.
TBH i tried all kinda stuff already and also am able to compare all logs with a Focusrite Scarlett 6i6, which shows
almost exactly same outputs but works just fine. This makes me clueless.
I also investigated if this could be a firmware bug, but then it would not work on osx either, no ?
Something new i found: if i capture from helix and play this file with scarlett all is fine. So it seems to be something with out-of-sync playback only.
Am 29.11.2017 um 15:51 schrieb Jorge:
On 29/11/17 13:26, Jens Verwiebe wrote:
Hi folks
I recently got a Line6 Helix LT which can work usb compliant for example on
Interesting. I would like to try the Helix in Linux too. I have seen similar issues when fiddling with set_sample_rate. Some comments/ideas below.
OSX or IOS. No driver is needed but the samplerate is fixed to 48000 ( which is okay for the first ).
Now i expected this device to work ootb in alsa, which turned out to be half the truth.
Connecting the device threw " usb 7-2: parse_audio_format_rates_v2(): unable to retrieve number of sample rates (clock 16)"
so i investigated a bit and found this workaround:
"/media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/clock (Kopie).c" 2017-11-08 10:06:31.000000000 +0100 +++ /media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/clock.c 2017-11-14 23:06:51.750924051 +0100 @@ -361,6 +361,13 @@ static int set_sample_rate_v2(struct snd struct uac_clock_source_descriptor *cs_desc;
clock = snd_usb_clock_find_source(chip, fmt->clock, true); + /* + * Line6 HELIX does not respond to sample rate + * set requests. The only valid rate is 48000. + */ + if (chip->usb_id == USB_ID(0x0e41, 0x4244) && rate == 48000) + return 0;
if (clock < 0) return clock;
"/media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/format (Kopie).c" 2017-11-08 10:06:31.000000000 +0100 +++ /media/Workdata3/Development/kernel_lowlat_4.4-97/linux-4.4.97/sound/usb/format.c 2017-11-14 23:12:24.329766243 +0100 @@ -293,6 +293,20 @@ static int parse_audio_format_rates_v2(s int nr_triplets, data_size, ret = 0; int clock = snd_usb_clock_find_source(chip, fp->clock, false);
+ /* + * Line6 HELIX does not respond to sample rate + * query requests. The only valid rate is 48000. + */ + if (chip->usb_id == USB_ID(0x0e41, 0x4244)) { + fp->nr_rates = 1; + fp->rate_min = 48000; + fp->rate_max = 48000; + fp->rates = SNDRV_PCM_RATE_48000; + fp->rate_table = kmalloc(sizeof(int), GFP_KERNEL); + fp->rate_table[0] = 48000; + return 0; + }
if (clock < 0) { dev_err(&dev->dev, "%s(): unable to find clock source (clock %d)\n",
This trick made the device appear in aplay -l and /proc/asound just as expected.
[ 7988.495085] usb 7-2: new high-speed USB device number 4 using xhci_hcd [ 7988.663622] usb 7-2: New USB device found, idVendor=0e41, idProduct=4244 [ 7988.663625] usb 7-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 7988.663627] usb 7-2: Product: HELIX [ 7988.663629] usb 7-2: Manufacturer: LINE 6 [ 7988.663630] usb 7-2: SerialNumber: 2744535
But i ended up with sometimes occuring soft clicks in playback which imply i have timing problems.
Another symptom is aplay does not output any sound while not throwing any error while in jack i can create the driver just fine.
Have you tried debugging the pointer position with that device? Do you get sensible buffer sizes with `-v` in aplay for 48KHz, 24 bits, etc?
I get just this but silence ( while plughhw:1,0 == scarlett looks same and plays sound ):
aplay -D plughw:6,0 -vv test.wav Wiedergabe: WAVE 'test.wav' : Signed 16 bit Little Endian, Rate: 44100 Hz, stereo Plug PCM: Rate conversion PCM (48000, sformat=S16_LE) Converter: libspeex (builtin) Protocol version: 10002 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 44100 exact rate : 44100 (44100/1) msbits : 16 buffer_size : 22050 period_size : 5512 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 5512 period_event : 0 start_threshold : 22050 stop_threshold : 22050 silence_threshold: 0 silence_size : 0 boundary : 6206523236469964800 Slave: Route conversion PCM (sformat=S32_LE) Transformation table: 0 <- 0 1 <- 1 2 <- none 3 <- none 4 <- none 5 <- none 6 <- none 7 <- none Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24001 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 24000 stop_threshold : 24001 silence_threshold: 0 silence_size : 0 boundary : 6755680916032454656 Slave: Hardware PCM card 6 'HELIX' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : MMAP_INTERLEAVED format : S32_LE subformat : STD channels : 8 rate : 48000 exact rate : 48000 (48000/1) msbits : 32 buffer_size : 24001 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 24000 stop_threshold : 24001 silence_threshold: 0 silence_size : 0 boundary : 6755680916032454656 appl_ptr : 0 hw_ptr : 0
I once ended up with really small buffers when I changed the usb audioformats for a fixed rate device so there was not sound whatsoever even though all the devices were present. I am not sure whether fp->rates should get SNDRV_PCM_RATE_CONTINUOUS either way and then min/max = 48KHz delimiting it.
Tried this already, makes no difference.
Jorge.
I would apreciate any hint what i could try out here.
Greetings from Hamburg ... Jens
My wisdom is at the end here ... Jens ;-)
participants (2)
-
Jens Verwiebe -
Jorge