USB Audio Adaptors not working on ar71xx

For Developers
1

Hi,

I have a number of USB audio adaptors that I am tried to get working with an Atheros AR9331 chipset router board. Every version I compile (tried historic and latest builds) has playback and recording issues. When playing back audio files (with alsa aplay) every other audio instance has what sounds like static or noise over it. When recording (with alsa arecord or sox rec) there is static and echo in the recording.

I then built the exact same OpenWRT build (recompiled) for an ipq40xx platform router board and used the exact same alsa settings and the playback and record is perfect! Does anybody have any idea why this might be? Why would it make a difference which platform it was built for and how can I replicate whatever (kernel or alsa) configuration works for the ipq40xx on the ar71xx?

2

Are you talking about WiFi USB adapters ?

3

Endianness issue/non-endian-clean device driver?

While ARM has selectable endianness, it's usually operating in little-endian mode just like x86 (I'm not entirely sure of this, but I've seen a lot of comments strongly implying this)

While OpenWRT on ath79 targets is most definitely big-endian.

4

The first thing to remember is that the SoCs supported by the ar71xx/ath79 platform are generally comparatively slow, single-core devices compared to the multi-core, ARM-based SoCs. You may never get acceptable real-time audio performance from them, especially under load.

As a side note, working with ath79 is highly recommended as the ar71xx platform has been EOLed at this point.

1 Like
5

Hi I'm talking about USB sound card audio adaptors like:

6

The ar71xx platform is a 400MHz CPU and I am recording raw 8-bit 8000Hz WAV. CPU usage (as measured with top) is less than 10% even with other processes running. Surely that would be ok?

The strangest behaviour is that playback is perfect every other instance of aplay, and then static/noisy the next! I suspect the problem is something to do with compiler options/endianness that sort of thing?

Update: Just tried with a 650MHz ar71xx (MIPS 24Kc) and still exactly the same issue!

Update2: Just tried with a 400MHz AT91 (ARM) board and also the same issue.

7

Same problem here with few possibly answers ?

Not my cup of tea but what they talk about “sounds” similar to your issue !!

8

Thanks but I don't think it's a hardware issue as it works perfectly when compiled for a different router but setup physically identically.

9

Have you tried using it plugged to a self powered usb hub connected to the router ?

10

Can we have it in Europe ? I have a free 10euros voucher for Amazon !!

11

Power supply is direct to 5V rail in all cases and can supply plenty of current

12

That’s what someone thinks could be the problem too much power on the usb line

13

I appreciate the thought, but it's definitely not a hardware issue

14

I've attempted to stream rtl_tcp data from an ar71xx, it would not work well without altering sample rates.

When I have time, I'll try setting it up again.

1 Like
15

@lleachii kind of missing out ! Do we have the sound card specs at hand ? Meaning what kind of chipset does the usb to audio/radio conversion ? Any reading to grasp the basics of it ?

16

Update3: compiled the exact same build of OpenWRT but for Raspberry Pi Model A target and the USB audio works perfectly, same as ipq40xx.

Why would it work fine for brcm2708 and ipq40xx but not ar71xx?

brcm2708 is single core 700Mhz so not much different to 650MHz ar71xx. Seems more like it's architecture related (compiler/build options?) than raw CPU speed performance?

17

Can you compare the output of the usb card information with the two different architecture ? Something like lsusb or cat about the stream process ? Could be the driver that set something wrong for ar71xx? Is the output of

aplay --dump-hw-params

Different ?

18

First of all, are you using snapshots or release?

Some Atheros devices doesn't work in full USB 2.0 mode when using ath79 so that might be an issue even though it "should" work but just barely. Also, what are you using to record? Keep in mind that you should record to a USB, Network Share (NFS as SMB/Samba will probably eat too much CPU) or /tmp (tmp is a bad idea as you will run out of memory quite easily but it'll do for short tests).

Preferably I think using ffmpeg is the best solution but arecord should work I suppose.

Sidenode: As far as encoding goes your best bet is using (fdk-)aac as it does just fine with integer operations.

19

Output is the same for both:

aplay /tmp/casio.wav --dump-hw-params
Playing WAVE '/tmp/casio.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo
HW Params of device "default":
--------------------
ACCESS:  MMAP_INTERLEAVED MMAP_NONINTERLEAVED MMAP_COMPLEX RW_INTERLEAVED RW_NONINTERLEAVED
FORMAT:  S8 U8 S16_LE S16_BE U16_LE U16_BE S24_LE S24_BE U24_LE U24_BE S32_LE S32_BE U32_LE U32_BE FLOAT_LE FLOAT_BE FLOAT64_LE FLOAT64_BE MU_LAW A_LAW IMA_ADPCM S24_3LE S24_3BE U24_3LE U24_3BE S20_3LE S20_3BE U20_3LE U20_3BE S18_3LE S18_3BE U18_3LE U18_3BE
SUBFORMAT:  STD
SAMPLE_BITS: [4 64]
FRAME_BITS: [4 640000]
CHANNELS: [1 10000]
RATE: [4000 4294967295)
PERIOD_TIME: (21333 21334)
PERIOD_SIZE: (85 91628833)
PERIOD_BYTES: (42 4294967295)
PERIODS: (0 17247242)
BUFFER_TIME: [1 4294967295]
BUFFER_SIZE: [170 1466015503]
BUFFER_BYTES: [85 4294967295]
TICK_TIME: ALL
--------------------
20

I'm using /tmp as the file sizes are only small (<1MB)

There are issues with both playback and recording. When playing back any WAV audio file it will playback perfectly once, then the next time it will play but will be "crackly", then play it again it will be perfect, then crackly....and so on.

Recording is harder to describe, it's like crackling but also like an echo and skipping. Recording at 8000Hz Mono 8-bit Unsigned should surely not be a problem for even a 400MHz CPU. Other much faster USB devices have no problems, such as mass storage or WiFi adapters.

Working: brcm2708 and ipq40xx
Not working: ar71xx and at91

Does that make any sense? Is there something that those platforms have in common?