Have you tried using it plugged to a self powered usb hub connected to the router ?
Can we have it in Europe ? I have a free 10euros voucher for Amazon !!
Power supply is direct to 5V rail in all cases and can supply plenty of current
That’s what someone thinks could be the problem too much power on the usb line
I appreciate the thought, but it's definitely not a hardware issue
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
@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 ?
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?
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 ?
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.
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
--------------------
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?
ar71xx (big endian) and at91 (little endian) don't support hardware floating point operations, have less RAM and are much slower (orders of magnitude) than brcm2708 and ipq40xx.
1 Like
I realise this is a rudimentary test but to test CPU performance I made a (albeit slow) python script to calculate all prime numbers up to 1,000,000.
700MHz brcm2708 took 5 minutes and 10 seconds
650MHz ar71xx took 5 minutes and 14 seconds
I think CPU speed is a red herring! Not to mention the fact that it is able to playback audio files perfectly (every 2nd time) and CPU usage is <10%. When recording we are talking a sample rate of 8000 bytes per second without any special encoding.
ar71xx (big endian) and at91 (little endian)
Sounds like we can rule out Endianness as well then!
Update4: playback and recording from USB audio working perfectly on 300MHz cns3xxx
Prime 1M benchmark for this board: 6 minutes 10 seconds
Working: brcm2708, ipq40xx and cns3xxx
Not working: ar71xx and at91
I really need to get this working on ar71xx! Is it worth me registering an issue on GitHub for whoever maintains ALSA Lib or something?
You're comparing apples and oranges, MIPS and ARM
Something that hit me, does the also occur if you try to capture in the same native format as the usb sound chip? You probably need to look in the driver or data sheet but it's usually 44.1/48kHz, 16-bit Stereo.
Wow yes that was a great find, thank you. That fixes the playback issue but now it won't let me record at all!
I created a /etc/asound.conf
pcm.dmixer {
type dmix
ipc_key 1024
ipc_key_add_uid false
ipc_perm 0666
slave {
pcm "hw:0,0"
### WARNING: do NOT add period_time, period_size or buffer_size here!!!>
rate 44100
}
bindings {
0 0
1 1
}
}
pcm.!default {
type plug
slave.pcm "dmixer"
}
But when I try to record now I get:
root@OpenWrt:~# arecord /tmp/test.wav
ALSA lib pcm_dmix.c:1043:(snd_pcm_dmix_open) The dmix plugin supports only playback stream
arecord: main:828: audio open error: Invalid argument
This config seems to do the trick! Thanks for the help everyone and great find Pippo
/etc/asound.conf
pcm.!default {
type asym
playback.pcm
{
type plug
slave.pcm "dmix0"
}
capture.pcm
{
type plug
slave.pcm "dsnoop0"
}
}
ctl.!default {
type hw
card 0
}
ctl.dsp0 {
type hw
card 0
}
pcm.dsp0 {
type asym
capture.pcm "dsnoop0"
playback.pcm "dmix0"
}
pcm.asym0 {
type asym
capture.pcm "dsnoop0"
playback.pcm "dmix0"
}
pcm.dsnoop0 {
type dsnoop
ipc_key 1025
ipc_key_add_uid false
ipc_perm 0666
slave {
pcm "hw:0,0"
rate 48000
channels 1
# period_time 0
# period_size 4096
# buffer_size 131072
}
}
pcm.dmix0 {
type dmix
ipc_key 1024
ipc_key_add_uid false
ipc_perm 0666
slave {
pcm "hw:0,0"
### WARNING: do NOT add period_time, period_size or buffer_size here!!! ###
rate 48000
}
bindings {
0 0
1 1
}
}
ctl.mixer0 {
type hw
card 0
}