Is anybody using a Raspberry Pi as a Stomp box? It is very fast at 800 or 1000 MHz with lots of peripherals and memory built in to the chip and there are different versions available. I was thinking that the normal RPi could be used to develop the code and then a Pi Zero that only costs a couple of Pounds could be used in the final box.
Having devoted a few years to learning the Spin FV-1 I'm a bit more oriented towards that but I am also a Pi enthusiast. While not geared towards stomp boxes, you might be interested in this online course. I'm taking it and you could probably sign up as it just got started. Uses Java.
https://www.kadenze.com/courses/creative-audio-programming-on-the-raspberry-pi/info
The main drawback of the Pi is the lack of integrated codec, but it's a good platform. I use a Pi 3 for my current project.
Why is a codec required? I was just thinking the RPi could easily shape a wave or act like a filter and clipper in software that would always give the same results instead of the analogue stuff that is based on variable component characteristics in the old circuit designs. All the manufacturers have gone digital for the reliability, repeatability, simple hardware and versatility for upgrades. I asked the question because I search the forum for Raspberry Pi and it gave no hits.
I am assuming real time software not involving an operating system on the RPi.
I meant that you probably need an ADC and a DAC to interface with the analogue audio world, unless you want to build a stompbox chain with digital connections only.
Ah! the lack of A/D is probably the reason. As you probably have guessed I haven't used the RPi for audio I/O yet. I remembered seeing an audio interface on the RPi but I have had a more detailed look and it is an audio PCM interface for talking to conversion chips so extra hardware is required to get the analogue data in to digital form. :icon_rolleyes: It would be better to pick a DSP that has onboard A/D to make things simple and cheap. Perhaps the PIC DSP32 is a good option. I can't see any posts about that either.
My recommendation would be to get a separate inexpensive ADC/DAC board then use that with the PI to leverage the huge support base from the PI community.
PI3 will be capable of far better audio processing performance versus, say an Arduino. It's harder to get audio in and out over the GPIO in a Linux OS. You'll likely need an I2S driver. Arduino will be easier to get audio in and out due to no OS, but is a much weaker processor.
Using a separate ADC/DAC let's you buy something cheap to get started, and get usable audio quality. Then later, you can invest in a better ADC/DAC/CODEC or build your own if you want pro level quality. This also gives you the flexiblity to move to another processing platform (like a DSP based one or even FPGA) later on.
Most audio based ADC/DACs use I2S as the serial protocol for transfering audio so it's each to change the codec or processing platform later. My first audio project used a small FPGA board with a couple very inexpensive boards from Digilent.
Here's what I used.
http://store.digilentinc.com/pmod-ad1-two-12-bit-a-d-inputs/ (http://store.digilentinc.com/pmod-ad1-two-12-bit-a-d-inputs/)
http://store.digilentinc.com/pmod-i2s-stereo-audio-output/ (http://store.digilentinc.com/pmod-i2s-stereo-audio-output/)
It depends on what you mean by 'stomp box'. A PI isn't meant for high performance audio applications - no audio quality delta-sigma ADC/DAC, Linux doesn't (easily) support low latency audio flow - low latency with respect to guitar effects which is ideally less than 5msec. Sure it's got MIP's but it's designed to run Linux, Bluetooth and Wireless stacks, perhaps a GUI, etc. PWM output will have low dynamic range compared to an audio DAC. PI could make a nice multi-effects controller and interface though. But if 'stomp box' means bit-crushing, not-so-low latency, reverb/looping, and experimenting then it might be just fine! Although seems that Teensy would be better for simple effects experimentation.
The RPi has the I2S interface for its audio input but for a cheap unit it gets expensive. The RPi is not limited to Linux Free Pascal can be embedded or applied to other ARM units and some other processors see here for starters.
http://wiki.freepascal.org/Embedded
I like the PIC idea because I have all the gear to program them, they have on board A/D and are cheaper than just one I2S peripheral. There is a simulator that could be rigged to take in a wave and give the output of your software before programming even programming a chip.
I wonder how good the A/D needs to be for a Stomp Box since we are only going to distort the original signal anyway so would 10 or even 8 bits be good enough?
Quote from: Ruptor on February 04, 2017, 01:21:22 PM
I wonder how good the A/D needs to be for a Stomp Box since we are only going to distort the original signal anyway so would 10 or even 8 bits be good enough?
What you're doing with the signal unfortunately doesn't reduce the needed bits. Reducing bits results in quantization error, which is often called 'digital distortion' but is nothing like the 'distortion' we are talking about intentionally creating in an analog circuit. Unless you're trying to create a low-fi 'bit crusher' sound you can't use resolutions as low as 10 or 8 bits.
Everyone's ears are different and what sounds like junk to one person may be fine to another. Here's a rough guide:
24-bits - this is used internally in digital processing to prevent roundoff error (quantization error) from accumulating. There is really no need for 24-bits in to our out of a stomp box, just for intermediate calculations.
16-bits - this is the standard for a reason. It guarantees that a perfectly sampled signal at this precision has qu antization error beyond the human ear's capability to perceive.
14-bits - this is the threshold where a good set of trained ears can start hear the quantization error (digital distortion) from a perfectly sampled signal. Most of us cannot hear this difference.
12 bits - this is where most people listening intently to the right recording can definitely perceive a drop in fidelity in a blind A/B test. This is still very usable though for experimentation.
10 -bits - this is might still be useful for very basic experimentation but the audio quality would not be good enough for use in a pedal.
8 bits - pretty awful and un-useable at this point.
The 12-bit I linked above ADC above is very 'useable' for audio experimentation purpuoses but you would want to upgrade to a proper 16-bit or better system for something intended to for use playing in a band, or recording music, etc.
OK that blows the PIC out the tail pipe along with any other micro with on board A/D I Guess. It is a shame the add on A/D boards are so expensive compared to the RPi zero for a couple of pounds. :icon_rolleyes:
Yes, Pis are very cheap. As always, life has tradeoffs.
As I said above, I like to keep the processor separate from the audio codec and use I2S to get audio in and out.
FPGA - ideal for audio applications, top performance, expensive and very difficult to program
DSP processors - ideal for audio applications, moderate performance, moderate price, difficult but not as hard as FPGAs.
multi-core embedded cpus (like Rpi) - very cheap, great processing power, easy to program, but complicated to get audio in and out with low latency. Usually Linux with RTOS patches required, but you could also skip the OS and go bare-metal if you can handle the low-level I/O yourself to get very low latency.
microcontrollers - like Arduino are easy to program, easy to get audio in and out of, fairly cheap but very very poor processing capability.
I had a look on Ebay and found 16 bit ADC on I2S for under £2. There are 12 bit DACs for the same money but curiously the 16 bit DACs are expensive at £6 but there are 16 dual DAC TDA1543 chips for less than 50p so the RPi zero with these would come it at less than £10 with 16 bit capability so it is viable. :) Going bare metal as they call it these days is the norm for me since I have been designing microprocessor based controllers for medical equipment for years. It looks like I will have to get in to real time embedded Free Pascal Compiler, FPC, which I know nothing about yet but it would be useful for other ARM based projects.
You might think about the Axoloti instead. I don't know exactly how it compares processor-specs-wise with the RPi3, but it's not an underpowered chip by any stretch. The large community around it and the GUI make the way in pretty easy.
I suspect the RPi world is focussed mostly on other stuff, whereas the Axoloti world is focused primarily on sound processing and synthesis.
HTH,
Tom
There are no PI Audio Codec HAT's available with guitar/instrument I/O with 1/4" jacks and proper input impedance and sensitivity for Raspberry Pi. Anyway, RPi is fine as Guitar FX unit but kind of overkill (in processing power and power consumption). You could though use the existing software like ecasound with LADSPA plugins to create a command line environment for processing the sound from the ALSA input to output (https://ecasound.seul.org/ecasound/Documentation/examples.html).
You need though program some kind of UI wrapper like a small Python program with simply Curses or more graphical WXPython or Kivy (https://kivy.org/#home) UI for configuring the ecasound commands and reading controls either pure MIDI or using external potentiometers and switches connected to GPIO, I2C or SPI ports.
Quote from: mhelin on February 05, 2017, 06:24:05 AM
There are no PI Audio Codec HAT's available with guitar/instrument I/O with 1/4" jacks and proper input impedance and sensitivity for Raspberry Pi
Sounds like a a great opportunity for a little DIY! I'm assuming the OP has some basic soldering skills.
This guy does the hard part for you, soldering down the small surface mount components and letting you interface to it with each 0.1" headers, but it still needs an instrument preamp. Note that sufrface mount ADC stuff is on the other side.
(http://cdn6.bigcommerce.com/s-7gavg/products/159/images/3825/Pmod_AD1__85519.1456865705.1280.1280.png?c=2)
On a solderless breadboard, add a 1/4" jack and a basic high-impedance preamp with variable gain. This will let you buffer the guitar signal, and set the preamp gain so the ADC sees a good signal without clipping.
(http://www.jer00n.nl/pics/opampbooster.png)
Once you've got everything working on the solderless breadboard, you can use a soldered breadboard and PCB mount jacks instead.
This guy gives you a buffered line-out at 1/8". A 1/8" to 1/4" cable will let you plug it into a line-in source (like your computer's line-in, or the FX Loop return on your guitar amp.
(http://cdn6.bigcommerce.com/s-7gavg/products/188/images/3853/Pmod_I2S__75529.1456866608.1280.1280.png?c=2)
The guy who designed the Digilent I2S pmod has also built a codec version of it:
http://ebrombaugh.studionebula.com/synth/codec_pmod/index.html
Maybe someone should hint Digilent to start building and selling these as well, and replace the 3.5mm connectors with proper 1/4" ones with the hi-z input buffer.
Quote from: mhelin on February 05, 2017, 08:16:36 AM
Maybe someone should hint Digilent to start building and selling these as well, and replace the 3.5mm connectors with proper 1/4" ones with the hi-z input buffer.
If there is interest in this kind of board, I could easily design a board with that codec and include a high impedance preamp and appropriate circuits to have instrument level in and instrument level out, just like a real pedal. It would have have proper 1/4" jacks installed. Probably optionally have MIDI IN / OUT circuits. What's the fun of a digital pedal if you can't control it with your MIDI Foot Controller?
Could probably get a batch of 10 done in about 8 weeks time frame. Once again, if there is interest.
Anybody have thoughts on that?
Been taking another look at the stuff available on Ebay. The best route for me is an STFM32 CPU board for £2 that has two 12 bit ADCs and a TDA1543 on the output for 50p with a couple of resistor and pots on the input and output. If 12 bit input is not good enough I can get a 16 bit board for another £2 so it would all come in under £5 with incredible versatility to do just about any effect in home made pedal. It suits my pocket and gives me something to play with off the shelf. :)
12-bit might be fine for guitar FX. Anyway, you can get I2S audio codec board to connect to Nucleo or other board for less than 10 $/£/€:
http://www.ebay.co.uk/itm/UDA1380-Board-Stereo-MD-CD-Mp3-Audio-Decoding-Decoder-Module-Development-Kit-AL/201493856369
http://www.waveshare.com/UDA1380-Board.htm
http://www.waveshare.com/wiki/UDA1380_Board
UDA1380 data sheet: http://www.nxp.com/documents/data_sheet/UDA1380.pdf
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.
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).
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.
Quote from: Transmogrifox on February 17, 2017, 07:12:05 PMI 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.
QuoteOf 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).
QuoteI 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.
Quoteso 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.
QuoteGenerally 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.
QuoteI 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..
Quote from: Transmogrifox on February 17, 2017, 07:12:05 PMOf 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. :icon_rolleyes:
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. :)
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.
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.
Quote from: Ruptor on February 19, 2017, 11:31:33 AM
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.
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.
Quote from: Ruptor on February 19, 2017, 12:47:14 PM
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.
Quote from: Ruptor on February 19, 2017, 04:41:46 AM
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.
Quote
What does Bela stand for? I am not up on the audio DSP jargon. :icon_rolleyes:
Actually this is not DSP jargon, it's a product:
bela.io (http://bela.io)
Quote10 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.
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 :icon_rolleyes: 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.
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
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).
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. :)
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).
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.
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.