OLinuXino A20: audio specs/quality?

[XFer]

Hello, new to the forum.

I already have a Olimexino board, very pleased with it.

Now I'm considering an A20-based OLinuXino, for a project about a stand-alone MIDI synth box.

Anyone has specs/infos/details about the audio capability of the board?
I.E., does it support 16 bit 44KHz stereo analog out with decent quality (SNR, THD)?

Thanks!

Fer

[Tom]

Hello,

the sound quality is not bad. I don't have the hardware to give you exact SNR and THD, but if you want to create a midi synth box, i can recommend to use an i2s dac. I don't know about the others, but the A20 has an i2s interface and it should be no problem to connect an external dac (most dacs out there are i2s). This way you can go up to 192Khz and 24bit (Not tested yet, my dac will arrive in two weeks). Samples that are sampled up to 192Khz tend to sound better than 44,1 and if you want to make a synth, you can use the higher resolution right away.

Good luck, i also use this mainboard for soundprocessing and i am very happy so far. I hope that the ES9023 dac i want to use will run fine on the olinuxino's i2s interface.

Tom

[XFer]

Hello Tom, thanks for your reply, very interesting!

I don't know much about external DACs, the few I know cost a lot ( = some hundreds euros/dollars).
The "ES9023" you mention is a full working daughter board, an external box, or just a chip in need of external components and a PCB to be designed? I have no way (knowledge/resources/tools) to design a PCB.

Right now I'm waiting for a working kernel with MIDI support (Debian Release 2 from Olimex has no MIDI support), then I'll start experimenting.

Fernando

[Tom]

I wrote you a pm. If you still have any questions, just ask. Designing a dac is not that hard, but there are also prebuilt options that leave all the 500 to 600 dollar commercial dacs in dust...

Tom

[XFer]

Thanks Tom!

In the meantime, I was able to run Fluidsynth on the A20 and tested the integrated DAC audio quality (headphones stereo output).
I have to say, I'm already very pleased! Sound is clear, clean, quite good!
So for now I can use the integrated analog output, and leave the I2S stuff for later on.

Fernando

[XFer]

A quick follow-up.

As is, Cubieboard2 3.3.0 kernel adds too much latency to Fluidsynth: about 85ms, unacceptable for live MIDI performance (my project).

I tracked down the issue: as a default, kernel timing is configured as dynamic (CONFIG_NOHZ), plus the sun7i ALSA driver has too high a minimum buffer size (larger buffer -> higher latency).

First I configured the kernel to disable dynamic timer, then I edited sun7i codec driver to reduce minimum buffer size.

This way, Fluidsynth could succesfully obtain a smaller buffer and reduce its MIDI latency.

Fernando

[XFer]

Some info about Olimex A20 audio capability.

It has an integrated DAC which is AC97 compliant.
With the kernel I'm using (Cubieboard2-derived, 3.3.0), ALSA sees 2 audio devices: HDMI (digital) and audio codec (analog).
The audio codec outputs to the stereo headphone out.
Its capabilities: sample rate up to 192KHz (44.1KHz default), SNR of 100dB (advertised).
HDMI digital audio should be I2S I suppose. The I2S interface of the A20 has a sample rate up to 192KHz (per channel) and a maximum depth of 24bit.

Fernando

[Tom]

Some info about Olimex A20 audio capability.

It has an integrated DAC which is AC97 compliant.
With the kernel I'm using (Cubieboard2-derived, 3.3.0), ALSA sees 2 audio devices: HDMI (digital) and audio codec (analog).
The audio codec outputs to the stereo headphone out.
Its capabilities: sample rate up to 192KHz (44.1KHz default), SNR of 100dB (advertised).
HDMI digital audio should be I2S I suppose. The I2S interface of the A20 has a sample rate up to 192KHz (per channel) and a maximum depth of 24bit.

Fernando

Yes, the quality of the A20 Board is very nice. Even the noise is really low, compared to other ARM Mainboards (it destroyes the Raspberry Pi for example), but wait for your es9023, this will make the olinuxino sound MUCH better...

Tom

[superpat]

Hi,

I am interested in using an A20 board with linux, and running mpd  using the inbuilt DAC. 

Has anyone done this yet?   (I cannot find "mpd" in a forum search)

thanks

Patrick

[XFer]

Never used mpd, but should work just fine.
I think there's a prebuilt package in Debian repository (it's not included in the Debian R2 image).

Fernando

[mattcamp]

Hi...

Has anyone tried using an I2S DAC/ADC for audio input on an A20 board yet?

The built-in interface appears to be mono only, and I'm looking for a way to get decent quality stereo audio input if anyone has any suggestions.

[rzr]

Can you compare to RPI audio (analog) output ? I found it quite weak ...

[leopard86]

Althought this thread is a bit old I hope somebody is still listening...

I am considering buying the Olimex A20 to replace a Beagleboard xM.
Some functionalities I need to decide whether to switch from the BBxM to Olinuxino-A20 :
- the audio input must have a pre-amp, so microphones can be directly connected
- the audio input should be stereo

Have people tested the in-out latency? E.g. how many buffers must Jack allocate at standard rates such as 44100 or 48k?

XFer said "I edited sun7i codec driver to reduce minimum buffer size", how exactly? And what's the latency you did get?
Regards

[netem]

I am also interested in finding out how the sun7i driver was modified to reduce the buffer latency. I also understand that the thread is old but that is the only one I found which has this information.Also what did you change the kernel timing to ?

[XFer]

Hello, returned here after 2 years and found those requests (1 year old).
I don't know if someone is still interested. Anyway.

At the time I was working on kernel 3.3. Current kernel is 3.4.107, but nothing changed vs. latency.

Here's the warning issued by fluidsynth on current A20 image with stock kernel:

fluidsynth: warning: Requested a period size of 128, got 1024 instead
fluidsynth: warning: Requested 2 periods, got 4 instead


Which means: instead of dealing with 256 bytes of audio buffer, it has to do with 4096. Larger buffer -> less chance of dropouts but higher latency.

To reduce audio latency, basically you need to:

1) Allow fluidsynth (or whatever software you are interested into) to allocate a SMALLER audio buffer
2) Check that your system is still able to play smoothly with the smaller audio buffer. This means upping the priority of the audio software, disabling any unneeded service, etc.

Ideally, a realtime kernel should be used, but that's a much more complicated task.

To allow for smaller buffer, we need to change something in the audio codec source.
The file is sunxi-codec.c

At the top of the source, look for the data structure

static struct snd_pcm_hardware sunxi_pcm_playback_hardware

Reduce the minimum buffer from:

period_bytes_min       = 1024*4,

to:

period_bytes_min       = 512,

and reduce the minum number of periods from

periods_min            = 4,

to

periods_min            = 2,


A few lines below, do the same to

static struct snd_pcm_hardware sunxi_pcm_capture_hardware



This will allow the caller to allocate a minimum of 2*512 bytes = 1024 bytes of audio buffers (instead of 4*1024 = 4096), thus potentially reduce the latency to 1/4 (IF your system can keep up without dropouts).
I don't recommend lowering the smallest period buffer to less than 512 bytes.

Keep in mind that the latency due to the audio buffer is:

audio_buffer_size / (sampling_rate * audio_bytes_depth * audio_channels)

so with the stock kernel:

4096 / (44100 * 2 * 2) = about 23ms minimum latency

with our tweaks:

1024 / (44100 * 2 * 2) = about 5.8ms

Of course this is only in theory; system load, services etc. may affect audio performances.