44.1kHz capture workaround??

[redhawk]

I need to capture audio at 44.1kHz sample rate but I am finding Linux is doing a pretty crap job at it.
So far I have thrown a Creative Lab Live 24bit and a newly acquired CM106 (aka HP-USB500) at my Pi but both suffer the same problems: samples are being missed / dropped at 44.1kHz but perfect capture with 48kHz or 24kHz.

Does Linux have something against 44.1kHz why can't it capture audio like a good Windows PC??

I'm trying to setup an online audio stream using Darkice but due to limitations in Flash based ogg players sample rate must be fixed to 44.1kHz.
Acc+ would be nice but the current builds are crippled with only ogg support and no mp3 or aac due to petty licensing whatnots.
Oddly enough Darkice does support re-sample but this forces my audio capture from stereo to 2 channel mono (a bug perhaps??).

Are there any workarounds for this really annoying 44.1kHz capture problem?

Richard S.

[jdb]

Assuming you are using the latest kernel/firmware, then there is an edge case for Isochronous IN transfers that can cause them to fail if a number of conditions are met.

- There's a hardware bug in the OTG controller: sometimes transfer complete interrupts happen coincident with the next SOF interrupt (i.e. the interrupt gets stuck in a queue)
- Your device returns 176-byte packets (likely to happen at 44.1kHz as the sample rate is not an exact fraction of the bus data rate)
- The hub is slightly laggy in processing packets
- The OTG transfer timing is such that the first request in a microframe is the isochronous IN endpoint

Then you can occasionally drop packets. Are there any errors in dmesg?

[redhawk]

With 48kHz sample rate capture I have no errors but at 44.1kHz I'm getting lots of:

Code: Select all

[  179.016924] Transfer to device 4 endpoint 0x5 frame 339 failed - FIQ reported NYET. Data may have been lost.
[  179.100922] Transfer to device 4 endpoint 0x5 frame 423 failed - FIQ reported NYET. Data may have been lost.
[  179.199927] Transfer to device 4 endpoint 0x5 frame 522 failed - FIQ reported NYET. Data may have been lost.
[  179.410933] Transfer to device 4 endpoint 0x5 frame 733 failed - FIQ reported NYET. Data may have been lost.
[  179.459917] Transfer to device 4 endpoint 0x5 frame 782 failed - FIQ reported NYET. Data may have been lost.
[  179.660923] Transfer to device 4 endpoint 0x5 frame 983 failed - FIQ reported NYET. Data may have been lost.
[  179.865934] Transfer to device 4 endpoint 0x5 frame 1188 failed - FIQ reported NYET. Data may have been lost.
[  180.055932] Transfer to device 4 endpoint 0x5 frame 1378 failed - FIQ reported NYET. Data may have been lost.
[  180.249931] Transfer to device 4 endpoint 0x5 frame 1572 failed - FIQ reported NYET. Data may have been lost.
[  180.418928] Transfer to device 4 endpoint 0x5 frame 1741 failed - FIQ reported NYET. Data may have been lost.
[  184.082934] dwc_otg_hcd_handle_hc_fsm: 27 callbacks suppressed

So I guess you're right it looks like a driver / hardware bug.
To be honest I'm surprised the Pi can capture 48kHz successfully but not something slightly less at 44.1kHz or even half at 22.05kHz.

Richard S.

[cyrano]

It's not unusual that audio works better at 48KHz...

44.1 is harder to packetize for a computer. Packets need to be padded. Doesn't happen at 48 because it's easier to divide. No padding needed.

[jdb]

A workaround is to capture at 48kHz and resample using Alsa to 44.1kHz. Libresample has a range of conversion filters for this purpose. In fact, 96kHz stereo capture should even be useable.

I have no idea what you would need to add to ~/.asoundrc to get it to work, though.

It's not unusual that audio works better at 48KHz...

44.1 is harder to packetize for a computer. Packets need to be padded. Doesn't happen at 48 because it's easier to divide. No padding needed.

"Packetisation" is irrelevant in this case: the OTG hardware cannot deal with the response returned by the USB hub for a specific data length and timing that is encountered at 44.1kHz samplerate.

[PeterO]

In fact, 96kHz stereo capture should even be useable.

It is with newer/newest firmware and kernels.
PeterO

[ragnarjensen]

A workaround is to capture at 48kHz and resample using Alsa to 44.1kHz. Libresample has a range of conversion filters for this purpose. In fact, 96kHz stereo capture should even be useable.

I have no idea what you would need to add to ~/.asoundrc to get it to work, though.

I have an idea

My .asoundrc for the Wolfson sound card might work with only small changes.
You would have to change the card name:

Code: Select all

card sndrpiwsp

to whatever the C-Media card is (probably "Device", check with "aplay -l")
and possibly the card number. I have my Wolfson set up as card 0.

Code: Select all

#######################################################################  
#  
# Use libsamplerate instead of internal resampler.  
# You might have to: sudo apt-get install libasound2-plugins  
# Or just comment out the next line if the internal one is good enough for your needs.  
defaults.pcm.rate_converter "samplerate"  
  
######################################################################  
#  
# Wolfson Audio Card for Raspberry Pi  
#  
pcm.my_virtual_sound_card {  
    type hw  
# CHANGE TO YOUR DRIVER NAME BELOW
    card sndrpiwsp 
    device 0  
}  
# Create a Master volume control  
pcm.softvol {  
    type            softvol  
    slave {  
        pcm         "pduplex"  
    }  
    control {  
        name        "Master"  
        card        0  
    }  
}  
  
pcm.!default  {  
    type           asym  
    playback.pcm   "plug:softvol"  
    capture.pcm    "pduplex"  
}  
  
#####################################################################  
#  
# Mixing and resampling goodness :-)  
#  
# Several clients can record and play back simultaneously.  
# The dmix and dsnoop plugins operate at 48kHz by default, i.e. the sound card will be kept at 48kHz at all times.  
# All playback streams are converted to 2 channels/48kHz/16bit.  
# All recording streams are converted from the card's 2 channels/48kHz/16bit  
# to the requested number of channels, sample rate and bit depth.  
  
# We define one pcm device called "playmixer" for playback.  
pcm.playmixer {  
        ipc_key 140324  # Any number will do, as long as it's unique in the system.  
        ipc_key_add_uid true  
        type dmix  
        slave.pcm "my_virtual_sound_card"  
}  
  
# Define another one called "recmixer" for capture.  
# The sound card will run at 48kHz and input is resampled to the requested rate.  
pcm.recmixer {  
        ipc_key 140325  
        ipc_key_add_uid true  
        type dsnoop  
        slave.pcm "my_virtual_sound_card"  
}  
  
# Define a duplex device, with both in- and outputs.  
pcm.duplex {  
        type asym  
        playback.pcm "playmixer"  
        capture.pcm "recmixer"  
}  
  
# Add a "plug" plugin for the above "duplex" device.  
# This is where all the converting takes place.  
# Sample rate, number of channels, bit depth.  
# By the way, who thought that "plug" was a good name for a plugin?  
#  
pcm.pduplex {  
        type plug  
        slave.pcm "duplex"  
}  
  
# A ctl device to keep xmms happy  
ctl.pduplex {  
        type hw  
        card 0  
}  
  
# A DSP to keep the alsa-oss layer happy:  
pcm.dsp0 {  
        type plug  
        slave.pcm "duplex"  
}  
  
ctl.mixer0 {  
        type hw  
        card 0  
}  
 

--
Ragnar

[valhallasdoor]

Just a little info, I saw this discussion and was inspired to record some audio. I down loaded Audacity and plugged in my USB Samson Meteor Mic. I opened Audacity and set the sample rate to 48khz and recorded a quick test. I was amazed at the playback!
I will be playing with it more this week and see if it holds its own.
I will check back with the results.

[metalj]

I also downloaded audacity and plugged my tascam us100 audio interface into the pi2 and recorded analog from my cellphone to my pi2 and had playback too.