"Robot" audio with snd-usb-audio

[Materdaddy]

I am one of the developers of an appliance application for the Raspberry Pi. With a VastElectronics HiFi-FMT V-FMT212R usb-audio FM transmitter there is an audio output problem on a Raspberry Pi. This problem does not happen from a Windows machine or my linux desktop machine, only when driven by a Raspberry Pi.

The description of the output is hard to describe for me as I'm not an "audio guy" but it's been affectionately dubbed "robot audio" because it sounds like a robot sound effect from a movie. You can still hear the underlying audio, but it sounds like it's being sent through some sort of futuristic digital tunnel. The problem will usually go away after a few seconds on it's own.

Here's a link to a video that shows the audio problem that can be observed from 0:06-0:18, 0:24-1:07, 1:18-1:37, 1:45-2:15:
https://www.youtube.com/watch?v=JL4BIKCtYig

Last year our users discovered that changing the volume will usually clear up the bad sound immediately, so a script was written to use amixer to change the volume up/down every second. I had another workaround that involved downgrading to a 3.10.33 kernel and adding "nrpacks=1" to the snd-usb-audio module parameters. That made the bad audio only last around 1 second instead of 10+ seconds, but the problem was not gone completely. Since the nrpacks option was removed in the snd-usb-audio module for a "smarter" way to choose this in recent kernels, I hard-coding the variable "packs_per_ms" in sound/usb/endpoint.c of a 4.1.6+ kernel, but the problem still exists in the form of 10+ second periods, so something else is wrong and last year's work-around may be a red herring.

This problem has existed in a range of kernels and seems to affect this usb audio device, but not others people have tried so it has something to do with the combination of this specific device and the Raspberry Pi.

I need help on how to properly debug this issue or provide logs/captures/etc. for a developer to fix.

Here's a link to a video that shows the audio problem that can be observed from 0:06-0:18, 0:24-1:07, 1:18-1:37, 1:45-2:15:
https://www.youtube.com/watch?v=JL4BIKCtYig

Affects Versions: 4.1.6+ (with firmware: 3f87086448257aa66881de858a0b4b0e6daa8719)

/proc/asound/cards:

 1 [Transmitter    ]: USB-Audio - VASTINT/FMT-212 Transmitter
                      Texas Instruments VASTINT/FMT-212 Transmitter at usb-20980000.usb-1.2, full spe

lsusb output:

Bus 001 Device 004: ID 0451:2100 Texas Instruments, Inc. 
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0 
  bDeviceProtocol         0 
  bMaxPacketSize0         8
  idVendor           0x0451 Texas Instruments, Inc.
  idProduct          0x2100 
  bcdDevice            1.01
  iManufacturer           1 Texas Instruments
  iProduct                2 VASTINT/FMT-212 Transmitter
  iSerial                 0 
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength          142
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      1 Control Device
      bInterfaceProtocol      0 
      iInterface              0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      1 (HEADER)
        bcdADC               1.00
        wTotalLength           40
        bInCollection           1
        baInterfaceNr( 0)       1
      AudioControl Interface Descriptor:
        bLength                12
        bDescriptorType        36
        bDescriptorSubtype      2 (INPUT_TERMINAL)
        bTerminalID             3
        wTerminalType      0x0101 USB Streaming
        bAssocTerminal          0
        bNrChannels             2
        wChannelConfig     0x0003
          Left Front (L)
          Right Front (R)
        iChannelNames           0 
        iTerminal               0 
      AudioControl Interface Descriptor:
        bLength                10
        bDescriptorType        36
        bDescriptorSubtype      6 (FEATURE_UNIT)
        bUnitID                 5
        bSourceID               3
        bControlSize            1
        bmaControls( 0)      0x01
          Mute Control
        bmaControls( 1)      0x02
          Volume Control
        bmaControls( 2)      0x02
          Volume Control
        iFeature                0 
      AudioControl Interface Descriptor:
        bLength                 9
        bDescriptorType        36
        bDescriptorSubtype      3 (OUTPUT_TERMINAL)
        bTerminalID             6
        wTerminalType      0x0301 Speaker
        bAssocTerminal          0
        bSourceID               5
        iTerminal               0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       1
      bNumEndpoints           1
      bInterfaceClass         1 Audio
      bInterfaceSubClass      2 Streaming
      bInterfaceProtocol      0 
      iInterface              0 
      AudioStreaming Interface Descriptor:
        bLength                 7
        bDescriptorType        36
        bDescriptorSubtype      1 (AS_GENERAL)
        bTerminalLink           3
        bDelay                  1 frames
        wFormatTag              1 PCM
      AudioStreaming Interface Descriptor:
        bLength                11
        bDescriptorType        36
        bDescriptorSubtype      2 (FORMAT_TYPE)
        bFormatType             1 (FORMAT_TYPE_I)
        bNrChannels             2
        bSubframeSize           2
        bBitResolution         16
        bSamFreqType            1 Discrete
        tSamFreq[ 0]        44100
      Endpoint Descriptor:
        bLength                 9
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            9
          Transfer Type            Isochronous
          Synch Type               Adaptive
          Usage Type               Data
        wMaxPacketSize     0x00c0  1x 192 bytes
        bInterval               1
        bRefresh                0
        bSynchAddress           0
        AudioControl Endpoint Descriptor:
          bLength                 7
          bDescriptorType        37
          bDescriptorSubtype      1 (EP_GENERAL)
          bmAttributes         0x01
            Sampling Frequency
          bLockDelayUnits         0 Undefined
          wLockDelay              0 Undefined
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         3 Human Interface Device
      bInterfaceSubClass      0 No Subclass
      bInterfaceProtocol      0 None
      iInterface              0 
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.00
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      28
         Report Descriptors: 
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x002a  1x 42 bytes
        bInterval              10
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x002a  1x 42 bytes
        bInterval              10
Device Status:     0x0000
  (Bus Powered)

[popcornmix]

@P33M and cmdline options that could help?

[P33M]

I've checked and it appears the default doesn't allow for the interrupt-as-bulk hack. Try adding the parameter dwc_otg.fiq_fsm_mask=0x0F to /boot/cmdline.txt.

[Materdaddy]

I sent PMs to a couple of our users (including the one that shot that video I linked) to try adding that to /boot/cmdline.txt. I received a PM back from that user today and directed the user here with your suggestion. I'll report back when I hear something. Thanks for the reply.

[cpinkham]

I tried this change and the problem is still happening. It didn't happen in the first 8 minutes or so of playing mp3 files after I rebooted, but then it started happening again. I'll leave it in place long-term to see if there is any effect. Yesterday afternoon when I tested before the change, the problem seemed to start happening more frequently the longer I was running a playlist playing MP3 files. The Falcon Player spawns mpg123 to play MP3 files..

Here's the cmdline.txt that I'm running with.

dwc_otg.lpm_enable=0 dwc_otg.fiq_fsm_mask=0x0F console=ttyAMA0,115200 console=tty1 root=/dev/mmcblk0p6 rootfstype=ext4 elevator=deadline rootwait spidev.bufsiz=102400

I believe this is stock other than the requested change and the "spidev.bufsiz=102400" increase. I am not using SPI on this particular Pi though, but the buffer size increase is something we apply to our Falcon Player image which is based on Raspbian.

[cpinkham]

Some longer term testing shows the problem is indeed still happening in fact sometimes I think it is worse now. When I was testing before applying the change, the problem would come and then go away by itself in 5-10 seconds, now it seems that more often than not, it will persist until mpg123 exits and a new mpg123 instance is started to play the next song in the playlist.

[Materdaddy]

I too can reproduce the robot sound with the same cmdline as Chris. I didn't notice anything with frequency of occurrence or anything, but what I did notice is that the additional setting does seem to fix a different sound issue.

Without the new setting to config.txt when I run dmesg in an ssh session I can hear some static in the audio. With the setting, it's nearly non-existent. It seems this setting is useful for some audio issues, but not the one we're trying to tackle here.

Depending on your location, I'd be willing to pay shipping (and return shipping) for you (@P33M or @popcornmix) to borrow this particular transmitter if you think that would aide in debugging this issue.

[Materdaddy]

Any other suggestions @P33M or @popcornmix ? Tips for debugging this further?

[Materdaddy]

FYI, this still occurs on Jessie running 4.1.15-v7+ kernel with firmware revision 12f0636cd11ebd7ec189534147ea23ce4f702e90.

[rdrehmel]

This issue does not seem to be specific to the Raspberry Pi or the mentioned USB device. I have the exact same issue on 4.2.0-30-generic #36-Ubuntu SMP on a x86_64 machine. The device connected to it is a Cortex-M4 microcontroller using my own USB audio 2.0 implementation. It's possible that my implementation - which is in the development stage - is provoking this behaviour, so it might actually my device's fault. In any case, I will investigate this further.

[rdrehmel]

Does anyone know the exact Texas Instruments IC the "VastElectronics HiFi-FMT V-FMT212R usb-audio FM transmitter" uses?

[wingrunr21]

I can't check mine at the moment but this page has an open source design that claims the FMT212R is a 1:1 hardware/software design. May be of use?

[rdrehmel]

If I interpret that page correctly, the FMT212R uses a TI TAS1020B.

[Materdaddy]

@rdrehmel My development machine is running a 3.16.0-4-amd64 kernel (debian jessie) and does not have this issue with the VastFMT transmitter. Neither does the kernel running on my beagle bone black (not up and running currently, but it is old because it is running debian wheezy).

I'll have to see if there's a newer and older kernel configuration for some platform so I can bisect kernel changes and maybe take this upstream since you think it might not be a Pi-specific issue. It could just be seen there in our testing based on kernel versions on the devices we've tried.

I'm not sure what TI chip the VastFMT uses, I haven't opened the case to find out, but based on the FmStick link, we might be able to assume the TAS1020B is correct. The VID exposed to the USB stack is 0451 and the PID is 2100. Unfortunately searching for those only seems to match one or the other but not both. The datasheet for the TAS1020B doesn't list a PID/VID because that appears to be something the OEM will program into EEPROM rather than something TI puts in the chip.

If you or @wingrunr21 tracks this issue elsewhere, please cross-link it, or contact me directly. I'd love to help when I have time/ability and the users of the software I contribute to would love resolution on this issue.

[Ruffio]

@Materdaddy has your issue been resolved? If so, please close this issue. Thanks.

[wingrunr21]

@Ruffio FWIW, this issue is probably seen most directly during the Halloween/holiday time period as the combination of a Pi + VastFMT is popular with the computerized holiday lights crowd (at least, that's how I discovered it and @Materdaddy's appliance is in that realm as well). I haven't tested my setup recently but could probably take stuff down and give it a whirl.

[Materdaddy]

@Ruffio, I have not tested lately as @wingrunr21 is right about the use-case that found this issue. This is something that will be coming up again very soon as people start prepping their holiday displays. Halloween will likely be first although most of our users have Christmas displays.

As far as I know this issue is still not resolved. I should have time this weekend to update to the latest raspberry pi kernel and test on a Pi variants.

For what it's worth, we do have reason to believe that this might not be a Pi-specific issue and may be a general flaw in the linux kernel. We had not experienced this problem on the BBB, pogoplug, nor x86-64 linux install, leading us to believe it was a Pi issue however a BBB with a newer kernel from Debian Jessie might have the same issue. If this is found to be the case, I'll likely close this issue when I investigate how to create and track one upstream with the mainline kernel. I may also try to figure out a method to git bisect minor kernel versions to narrow down what might have caused this problem.

[Materdaddy]

FYI, I'm revisiting this issue and am looking for anybody who can give advice that is familiar with USB-audio devices and how I might go about investigating this issue efficiently.

I went down the path of using usbmon to capture traffic between the kernel and the VastFMT device. I have a few captures using https://github.com/swetland/usbmon of a single song played back using mpg321 and alsa that have the same exact output. I also have one playback capture with "robot audio" that differs. The data shown in the usbmon binary differs from near the beginning of the capture even though the "robot audio" wasn't observed until near the end of the playback. Unfortunately I'm not familiar enough with the actual data within the usb traffic to decode the data to determine why the data might be different from the beginning. Also of note, the output of the usbmon application does not match the output of the "/sys/kernel/debug/usb/usbmon/*" devices, so I'm not sure if I need to add additional fields to gain useful information.

Suggestions of where to go from here are welcomed.

[P33M]

There have been a few bugfixes in the latest rpi-update kernel that may impact on this use-case. Please try again with an updated Pi.

[Materdaddy]

@P33M thank you for the update. I will try to reproduce this again within a week and provide feedback.

[JamesH65]

@Materdaddy Did you have a chance to look at this?

[Materdaddy]

I didn't find time yet, but I received a PM from @cpinkham with the following:

I have a Pi running the latest Raspbian Squeeze and FPP master-v1.x and it still has the FMT-212R audio glitch in it: The kernel version is 4.9.56+. I ran a "rpi-update" before testing to pull in the latest firmware and kernel. Here's the "uname -a" output if you are interested.

Linux FPP 4.9.56+ #1044 Fri Oct 13 15:17:45 BST 2017 armv6l GNU/Linux

I started playing and within a minute or so the problem appeared. Changing the volume up/down by one notch fixed the audio, but that still isn't anywhere near acceptable.

[JamesH65]

Sorry about delay. Not sure if we have made any changes in sound, but there have been changes in the USB, so may well be worth trying with the latest Raspbian. Unfortunately this is not a high priority for us, so we are not working specifically on it, but changes elsewhere in the USB stack may well be helping.

[JamesH65]

Please update to the latest kernel which may contain a fix for this issue.

This issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

[JamesH65]

Closing due to lack of activity. Please request to be reopened if you feel this issue is still relevant.