USB audio interface instead of hifiberry?

Is it possible to use a USB class compliant audio interface rather than a hifiberry. ?

Any downsides or upsides?

It’s perfectly possible. The only problem is the slighty greater latency. The USB port circuitry/drivers add some extra time to the loop, but probably it’s OK if you use a decent USB audio interface.

Regards,

Havn’t tested yet, but a HDMI->Audio-Interface may also work (with some additions inside Zynthian).

Regards, Holger

Can we add a ‘sticky’ thread where people can post success (&failure…) stories about supported audio cards? I know that there is a list in the wiki & support for different cards in the webconf, but it would be good to know which cards have actually been used.

I tried to get one of these working, but gave up… https://www.ebay.co.uk/itm/DAC-HIFI-DAC-Audio-Sound-Card-Module-I2S-interface-for-Raspberry-pi-3-2-B-B-MO/152333412709?epid=2230952529&hash=item2377c76965:g:WGMAAOSw6AlZwc4U

Audioinjector Zero. Nice price tag, audio in. In my opinion there is no better choice.
I have hifiberry also

1 Like

That would be great indeed, as I was looking for the same and didn’t find that much really detailed information. We could also collect measurements regarding several audio quality parameters, as for some cards there is not much specs to read.
I am preparing a comparison table of audio cards with all those technical specs, connectors, things to know when using a certain audio card inside a Zynthian Box (as I just collected a lot of that to know for my own Zynthian build). As soon as I got this to a certain stage, I will publish it in the wiki so maybe based on that we can collect any information on audio cards there too.

Grooving Regards,
Bernhard

Where do you live, Bernhard?
If you are at non-shipping distance from Frankfurt, I can lend my second AI Zero.

Or you tell us, how to measure what.

Yes @mheidt, I am living in your area! :slight_smile: I sent you a private message about that.

In general, parameters that would be interesting are (to have a start at least):

  • Signal Noise Ratio. If the device has a dedicated headphone out (and therefore an amp), it would be interesting to measure that output as well, I guess.

  • Total Harmonic Distortion, maybe.

  • Crosstalk between channels (well hopefully not)

  • Latency between an incoming Midi signal and audio out

  • Latency between an incoming Audio signal and the same signal arriving at output (routed directly)

I have to admit that I have never measured any of these so far, but since this actually is heavily connected with the subject I study, I’m hooked and I will find out how to do it exactly…

Grooving Regards,
Bernhard

Hi @freeKey,

perhaps you can also measure a real latency (MIDI->Audio-out)?

Regards, Holger

Hi @C0d3man,

of course, that’s what I meant with the first latency thing. While the other values are so much hardware-only stuff (DACs etc) that they relate to the audio card in general, those latencies only make sense in a Zynthian environment. Perhaps it also slightly depends on the engine used, so maybe we test different settings.
Do “heavy” patches mean more latency as well? Zynaddsubfx with a simple sine vs Zynaddsubfx with something really complex, or what about bigger Salamander Grands in Fluidsynth?

Grooving Regards,
Bernhard

Pianoteq is interesting.
And I had the most noise with the Salamander in LinuxSampler.

I hope my understanding of audio processing is right:
Some algorithms add latency, some not. Normally a synth, reverb, eq should not add latency. So you have the buffer size (window) of N bytes for a samplerate S of your audio software for calculations - regardless of calculating a simple sine (with lookup-tables) or a complex sound. If your program cannot calculate the N bytes in the time needed for the samplerate S you get drops because there is an empty buffer. The only way to avoid this, is to add more CPU power, optimize the algorithm (reduce polyphony, lower internal samplerates, tweak the code, optimize the compiler flags,…), use a lower samplerate and/or a bigger buffer (this adds latency).

Some algorithms (e.g. a compressor witch adds a number of buffers as latency for avoiding peeks) add latency. But the most algorithms do not. In LV2 plugins there is the possibility for telling the host how much latency is added - I think this is also true for VSTs.

So, the minimum latency for Zynthian is the sum of the MIDI latency (normally 3 bytes for a note-on at 31250 bits/s = 0.768 ms) plus internally handling for queueing of the MIDI message plus latency of the DAC in the audio card plus buffer_size*1000/samplerate (e.g. 256[bytes]*1000/44100[Hz]=5.8ms). I think for a Hifiberry DAC+ this should be about 10ms.

I think for a stereo signal you have to double the 5.8ms, or?

Regards, Holger

Finally I had my Audioinjector Zero und HifiBerry Pro working in parallel.
The HifiBerry is louder and has less noise, when you crank up the volumes up to max (where it never should be)

But it’s ok in the normal range. Numbers would be nice now.
In the end it’s a decision if you want to pay double the price for no IN.
And I had the feeling, that the MacBook Pro of my collegue had more noice than the Audioinjector.

But there were so many other parameters like cable etc. so that I shouldn’t compare it.

1 Like

Do you think is the DAC or the board design? You know i’m thinking of using the Audioinjector’s ADC/DAC chip for future developments in Zynthian HW … ,-)

I have no clue. Maybe it just needs a shield from the raspiboard?
We need numbers. Maybe it’s not that critical.

1 Like

joe, please consider something with better specs.

FYI, during my first stages of playing with Zynthian I’m using Topping NX4DSD as audio interface and headphone amp (DT-880). Latency is really small [negligible, no feeling of lag at all, even at 512 (or is it 256?) buffer in jack config, RPi4, pianoteq, no cracks/stutters], and That Sound… I don’t even try to look elsewhere. I do really hesitate to try that some I2S WM8731 board I have laying here somewhere. Though having input on Zynth is tempting.

1 Like

That’s a bit unfair. The Rpi4 didn’t exist in 2018, but you are right! It’s a big improvement.

Actually, minimum MIDI latency is 0.96ms because MIDI is 8-bit data word plus 1 stop and one start bit, hence 10 bits per word. Some MIDI messages are shorter, e.g. real time messages like MIDI clock are single byte hence minimum 0.32ms. Also running status allows for data thinning by not sending the status byte which reduces minimum latency to 0.64ms. Things are further complicated by Zynthian’s attempt at variable tuning so each MIDI note on message is preceded by a pitch shift which increases message length (effectively doubling latency) and removes ability to use running status. (But that is the subject of a different (new) topic :wink:.)

I think the idea of a table of devices that have been tested with Zynthian is a good idea. It should include the statistics that @freeKey suggests (for both input and output) plus an indication of success, i.e. include any interfaces known to not work with Zynthian. This is an endless and error prone venture and is bound to become outdated or inaccurate because we don’t have unlimited resources to acquire, test and retest devices but I see benefit in trying. An additional data may be a confidence level of the result. I have seen similar tables where the result may say that the test result is not validated.

Well done for volunteering!!! There should be a description of the test process to allow users to contribute data in a (reasonably) consistent way.

1 Like

These numbers are only valid when you consider 2 hardware devices communicating with a standard MIDI interface. I’m not sure how this apply to MIDI-USB, that is a different kind of beast. Regarding MIDI@JackAudio, latency is fixed by the configuration options.

These “tuning” messages are totally internal, flowing thru the jackd system, from the ZynMidiRouter to the engine, in the same “frame time”, so no added latency nor jitter.

Regards,