[alsa-devel] Line6 Helix - usb compliant but not working correct

[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 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
>