Raspberry Pi

[Blackaddr]

Just keep in mind none of these boards operate at instrument level, or high impedance.  You will still need to add a Hi-Z preamp in front of the ADC and another circuit on the back end to bring it back down to instrument level if you intend to feed the output into another guitar pedal or your guitar amp.

[mhelin]

Input amp to UDA1380 is an inverting amp with 4-bit PGA control (upto 24 dB gain) and another PGA in decimator. So you can use a large input resistor to match the impedance (something like 220 kohms and up, 1 Mohms resistor might be too noisy together with needed PGA gain).

[Transmogrifox]

FYI if 5ms latency is ok, I did get my PI3 to do some guitar effects using a USB CODEC (UCA202).  If you don't want to hack in a Behringer board, then you can use the PCM2902 on your own board directly.

I used Linux and Jack Audio Connection Kit (JACK) as my RT audio API.  By disabling most services and running it as a command-line application only I was able to get 64 frames per period @ 48 kHz (1.3 ms in, 1.3ms out + CODEC latency (1ms) = 3.6 ms) latency.  I call it roughly 5 ms because I didn't actually measure it.

Of course you have to suffer Linux boot time, and that all depends on how you optimize your Linux.  Also there is the question of the control interface which requires more external stuff.  You could use I2C ADC's for reading inputs.

Of course you could do bare metal and be practically instant-on, and lower latencies but then you have to write all the drivers and stuff that goes around it.

As for the PI itself, it has a CPU that can do all the number-crunching you are likely to do, and there is enough RAM for a pretty long looper effect.

I finally got a Bela because for me it's just a hobby -- I don't have any visions of developing something and selling boatloads of them.  The BBB has enough horsepower for the stuff I want to do and the Bela cape gives me all the analog and digital I/O I will use.  Really sped things up for me having all the RT audio stuff ready to go.

[Firesledge]

I used Linux and Jack Audio Connection Kit (JACK) as my RT audio API.  By disabling most services and running it as a command-line application only I was able to get 64 frames per period @ 48 kHz (1.3 ms in, 1.3ms out + CODEC latency (1ms) = 3.6 ms) latency.  I call it roughly 5 ms because I didn't actually measure it.

I use the same frame length but actually did measure the latency and obtained about 13 ms for the round trip. Anyway nobody using my pedalboard noticed it (until I told them—shock!) so I guess that latency figures are nothing more than figures for most people.

Of course you have to suffer Linux boot time

Generally plugging all your stuff or waiting for the tubes to warm up is longer (8 s boot here).

I finally got a Bela because for me it's just a hobby

This Bela is a really nice thing (it just needs high impedance input buffers). I which I could build something as good for the Pi.

[Transmogrifox]

so I guess that latency figures are nothing more than figures for most people.

I think so.  One way to put it into perspective is an 1/8th note at 130 BPM is about 230ms, and a 1/16th note is 115ms...so you're starting to lag if you play 32nd notes synchronized with another musician who is playing 32nd notes.

I stand by the rule of thumb that 20ms is where the latency becomes perceptible.  I would guess some people would sense a mild agitation at 13ms if they noticed it at all.

Generally plugging all your stuff or waiting for the tubes to warm up is longer (8 s boot here).

It's a good point that there are few instances where even 1 minute causes problems practically.

Bela takes a good 30 seconds, and it's ready to rock by the time I get my guitar out of my case, track down some picks and plug in.

I which [wish?] I could build something as good for the Pi.

If one were to do bare metal programming on the PI one could probably make it work directly with the Bela cape (or spin a footprint compatible board).  The one thing the Beagleboard has is the PRU which simplifies all the bit-banging and DMA stuff in the background.  Either way one core could be primarily dedicated to handling audio and analog I/O and the other 3 available for the stuff you really want to do.

The main advantage of the Pi is it's really low cost (especially the Pi Zero)...again, an advantage for somebody intending to make a marketable end product but not for somebody like me who can afford the cost of a Bela but can't afford the development time to overcome some of the Audio I/O obstacles with the Pi..

[Ruptor]

Of course you could do bare metal and be practically instant-on, and lower latencies but then you have to write all the drivers and stuff that goes around it.
I finally got a Bela because for me it's just a hobby -- I don't have any visions of developing something and selling boatloads of them.  The BBB has enough horsepower for the stuff I want to do and the Bela cape gives me all the analog and digital I/O I will use.  Really sped things up for me having all the RT audio stuff ready to go.

Isn't there software drivers around somewhere for driving the UDA1380 based boards that seem to be pretty standard? The chip manufacturers usually supply drivers to push their products. I bought this one to attach to my RPi
http://www.ebay.co.uk/itm/1Pcs-Audio-Decoder-Module-Uda1380-Board-Stereo-Md-Cd-Mp3-I2s-Interface-J/132092290199?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D2%26asc%3D41396%26meid%3Dcf8335f50e764a7f8f8b31d3db23619e%26pid%3D100005%26rk%3D1%26rkt%3D1%26sd%3D112234715126
What does Bela stand for? I am not up on the audio DSP jargon.
From work I have done on user button pressing 40mS seems to be the limit where nobody can press buttons any quicker and I would place the perceivable detection for one person would be 10 mS but if you go by the sound and run two signals together I think you can hear a 10mS difference which is a different aspect to the latency. I don't know if normal music conditions would allow you to hear a 10mS difference especially if you have a spliff in one hand and a beer in the other.

[Blackaddr]

I am concerned that you're still going to need to build a preamp to use that board.  If you look at the datasheet, it shows the inverting op-amp feeding the ADC.  An inverting op-amp has two resistors in the circuit, the feedback resistor Rf, and the input resistor Rin.  Rf is digitally changed as part of the PGA function. Rin is fixed at 12K.

The input impedance of an inverting op-amp circuit is the value of Rin.  So that chip has input impedance 12K. The gain is -Rf/Rin.

12K is standard for a line in, but unusable for guitar at instrument level, it needs to be closer to 1M if you dont' want tone suck.  If you put a series resistor on the input, you effectively boost the input impedance but you are reducing the Rf/Rin gain.  Boosting Rin from 12K to 120K for example reduces your gain by 10x which is 20db.  The PGA has 30 dB of gain which is roughly 32x.  So 12K x 32 = 384K.  This means, once your added resistor + 12K hits 384K, you actually get unity overall gain when the PGA is maxed out.  Anything higher than that added to Rin and you now get attenuation.

This is why op-amp based guitar preamps are always built with non-inverting op-amps where the input impedance is independent of the gain, and starts at tens of megaohms.  You set precisely the impedance you want with a resistance from input to reference because the feedback path and input path are independent.

Inverting op-amps are not suitable for high impedance applications because Rin must be very high (say 1M), and in order to get 30 db of gain, Rf must be about 32M, and with resistors that high in the feedback path you get a slew of problems.

Go build yourself a board with proper 1/4" jacks, and a JFET (not BJT) based preamp circuit. A TL072 is a decent choice for op-amp.

[Ruptor]

Yes I hear you but I would opt for a simple single stage JFET input that can work from a single supply and only requires a 1 M resistor to ground for gate bias. As you say I need 1/4" jacks so I can put the JFets on that board.

[Blackaddr]

Yes I hear you but I would opt for a simple single stage JFET input that can work from a single supply and only requires a 1 M resistor to ground for gate bias. As you say I need 1/4" jacks so I can put the JFets on that board.

a JFET unity gain follower in non-inverting format is good (short between output and op-amp) should be fine. 

Just to be specific, for single supply, you need to bias the input to half the voltage.  This means you have resistors from the op-amp + pin both to PWR, and another to GND like a voltage divider.  If power is 9V, this biases the input to 4.5V.  The resistors should be identical value equal to 2x your desired input impedance.  So, if you use 1M for both resistors the actual input impedance will be 500K.  If you use 2M resistors, input impedance will be 1M.  If you use 500K resistors, you'll actually have 250K which is too low.

You also will need a higher voltage to run your JFET opamp like a TL07x, you can't use 5V or lower voltages that might be available on the ADC board. So you'll need to add another supply that is different than the 5V or 3.3V running the ADC. 9V to 12V is good for a JFET op-amp.

With a unity gain buffer, the PGA in your ADC will provide 30db of gain which is more than enough for a direct connection from a passive guitar pickup.

HOWEVER, if you put another pedal in front of it, the output of a 9V pedal could easily be 7V peak to peak in which case you would overload the ADC so be careful there.  Active pickups also easily put out more than 1V pp, so just be careful if you use active pickups for the same reason.

[Ruptor]

I think we have crossed wires. I envisage using a JFET single transistor not an opamp. JFETs are depletion mode so the junction only requires a gate resistor to ground and it can easily drive the 12 K load of the ADC board. I can use either the 12V or 5V given to the RPi as the JFET supply but I haven't looked at things in depth yet. Getting the software off the ground is looking like the tricky bit to me. I have been wanting to use Free Pascal for embedded work but never got round to it because I hate C.

[Blackaddr]

I think we have crossed wires. I envisage using a JFET single transistor not an opamp.

Yup, I totally missed the single FET buffer, assumed you meant JFET op-amp.

[Transmogrifox]

Isn't there software drivers around somewhere for driving the UDA1380 based boards that seem to be pretty standard? The chip manufacturers usually supply drivers to push their products.

Certainly, but you still have to implement it all from the ground up and get the correct I/O pins assigned, set up the interrupt handling sub-system and audio-thread calling functions...it's a lot of work that as far as my searching I have seen nobody has published for the Rpi publicly.  Maybe as time passes somebody will take it on and make a really nice bare-metal platform and a daughter board sort of like Bela for the Rpi.

What does Bela stand for? I am not up on the audio DSP jargon.

Actually this is not DSP jargon, it's a product:
bela.io

10 mS but if you go by the sound and run two signals together I think you can hear a 10mS difference which is a different aspect to the latency.

Yes, that is essentially a flanger stuck in one position.  It is also a natural effect just by standing in front of a pair of stereo speakers at a position where one is 10 feet further from the other.  Part of this gives us our sense of direction and this is why something like a stereo flanger or stereo chorus can sound so "wide".

If mixing an original signal with a delayed signal you hear a comb filter effect up to about 20 ms.  Somewhere between 20ms and 50ms is where we start to detect the delay as more of an echo/repeat rather than a filter.

But for a guitar effect, when you strum the strings the question is how much delay before it feels like an unnatural amount of time between strumming and hearing the initial attack of the first tone? 

My experience is I don't really notice up to 20ms, but 40+ms will drive me nuts.

One place I did notice 10ms was with a looper, because every time through the loop my timing was based on the last thing and after several iterations stuff started to feel "off" because I was successively adding latency with each loop so each track caused me to get confused...I could have kept it in control by carefully listening to the base track, but it just gets out of control after a while.

That particular problem can be corrected by recording ahead of the current time to compensate latency so the currently recorded track gets laid down in sync with the base track timebase, pre-adjusted for latency.  It will be off by the initial delay while going in, but after you hit stop and play it back it will be played back at the correct time from the recording.  Then you never confuse yourself and get off by more than a single multiple of the system latency.

[Ruptor]

I received my little UDA1380 board that has microphone and earphone I/O as well as the line in & out sockets. It is very complex to program so I am looking at software examples like this
http://docs.lpcware.com/lpcopen/v1.03/group___b_o_a_r_d___c_o_m_m_o_n___u_d_a1380.html
to try and get a handle on things.

[mhelin]

UDA1380 is supported by the Linux kernel, so the codec drivers are available. What you need is a platform driver which combines the codec driver with the ARM / RPi / Broadcom BCM2708 I2C and I2S ASoc drivers. This is explained in details in Koalo's blog:

http://blog.koalo.de/2013/05/i2s-support-for-raspberry-pi.html

However, since then RPi linux has introduced the device tree concept in which a small I2C flash memory on RPi "HAT" compatible devices (like the available DAC boards like Hifiberry DAC) hold some configuration data (like on old ISA plug and play system). You can still manually do the same stuff, modprobe the required drivers in correct order and have a fully functional input/output device on RPi using that UDA1380 board - assuming there are needed signals. One thing I can see missing is the MCLK signal or master clock, RPi does not have MCLK (system clock) output so you have to bring that from the codec board but I'm not sure if the UDA1380 does have that. The codec board does have MCLK input and think can generate other clocks so you have to build a small oscillator board using a 3V3 24.576MHz crystal oscillator, or use a PLL based circuit tracking RPi word clock output like presented on this appnote: http://www.ti.com/lit/an/scaa088/scaa088.pdf

[mhelin]

Above mentioned the 24.576MHZ clock, that is of course able to make clocks only for n*48kHz sample rates, for 44.1kHz derivates you need another one, for an example 11.2896MHz you can also halve the 24.576MHz and use 12.288MHz clock as well (might be you can't use it for 96Khz sample rate though).

[Ruptor]

I am sure at a low level the RPi has everything to talk to the UDA1380 since it has many timers and clock options. It can generate a 100 MHz carrier for FM output so it has high clock speed capability. None of the off the shelf software will be using its unique freatures but it doesn't stop us from using them in embedded Linux where we can do what we want.

[mhelin]

No you can't do everything even in bare metal style. Some of the I/O functionality including (afaik) PCM/I2S interface is implemented on the VideoCore side where you have no full access (you have some API to use VC but not access to the I/O).

[Ruptor]

I don't understand what you mean by video core. The audio board I bought is meant for the Arduino so if that can drive it I am sure the RPi can. I don't need all the complicated bits just input and output conversion the RPi will do the rest.

[mhelin]

There is indeed a way to lock the UDA1380 to incoming LRCLK (frame sync) even without the MCLK which RPi cannot generate. See chapters 8.1 and 11.1 on UDA1380 data sheet:

http://www.nxp.com/documents/data_sheet/UDA1380.pdf

There is actually a PLL called WSPLL which can generate the internal sync signals from the frame clock. You need to set the required bits in I2C register 00h. To get the interface working after connecting the I2C and I2S to and from RPi and UDA board you should have the driver snd_soc_uda1380 installed properly. Currently there is no soundcard  (machine) device for RPi which combines the RPi PCM/I2S driver ("platform driver" in ASoC terms) with the codec driver. Anyway, the uda1380 codec driver already sets the PLL stuff so you don't have the take care of the programming ( see https://github.com/torvalds/linux/blob/master/sound/soc/codecs/uda1380.c ). What we are still missing is the machine driver which combines the RPi PCM device driver with UDA1380 codec driver. That could be made by combining parts of an existing RPi machine driver like the Hifiberry DAC driver (just add the recording interface) and some other UDA1380 related machine driver for the UDA1380 parts. I linked an internet page giving an example above.