In case anyone is still looking to use I2S with Bela, here's a repo that might be useful:
https://github.com/martin-minovski/Bela-I2S-IN
Cheers
In case anyone is still looking to use I2S with Bela, here's a repo that might be useful:
https://github.com/martin-minovski/Bela-I2S-IN
Cheers
Each I2S port can only have 2 input and 2 output channels. However, on the BeagleBone, the same ports (called McASP) can be turned into TDM (time-division multiplexing), supporting up to 16 inputs and 16 outputs, which is what we do for the CTAG (although we only use 8 inputs). Additionally, you could think of bitbanging the protocol on some spare pins, as minovski did above, thus increasing that count, but I am not sure then what the maximum number of channels would be at that point!
Clearly, this is just for the digital communication to the board, however, you'll also need some ADC converters that convert from analog to I2S, if you really want to increase the channel count.
giuliomoro We have a board, which has support tdm intput and output.
So how can i connect my tdm board with bela?
You need to be more specific than that, and be prepared, this is a serious undertaking.
What do you want to achieve?
Thanks for the info on I2S on bela, @giuliomoro and @minovski !
I would like to connect a bluetooth module to a bela mini to stream 2 channel audio (or, perhaps, also stream a microphone signal back in a headset mode while receiving a monaural audio stream). The I2S protocol appears to be best-suited for that. But getting this to work looks a little complicated to me.
If I understand correctly, the MPU's McASP units can be configured to the I2S protocol, but the available pins on the pocketbeagle only allow for use of McASP0 (and a few McASP1 pins). Now some of these pins are already required for the bela cape.
Hence, receiving an I2S signal could still be possible via these pins:
- P2.04 (mode 6, McASP_AXR)
- P2.08 (mode 6, McASP_ACLKR)
- P2.06 (McASP_FSX)
However, transmitting a signal back is not possible, since pin P1.36 (McASP_ACLKX) is already occupied by the bela cape (although pins P2.06 (McASP_FSX) and P2.02 (McASP_AXR) are available).
So this is where minovski 's solution could come in, implementing the I2S protocol via the bela mini's second PRU. However, the code references several hex addresses for pins, which are a bit hard to decipher. That makes adapting this from the bela to the bela mini a bit difficult for me. Could I just enter the addresses for any pin connected to PRU1 there in pru_gpio.p (i.e., P1.02, P1.04, P1.30, P1.32, P1.35 and P2.11, P2.31, P2.35)?
Many of these pins are used for digital IO on the bela mini, but can be reconfigured via the pinmux, I read.
Is all this correct? Is there a better way to integrate a bluetooth connection?
Would it then be possible to read the I2S input via the audioIn function or would I have to implement another function for this purpose?
Cheers
Would you use the Bela codec as well? Would you send the same signal to the Bela audio out and the I2S BT module?
giuliomoro Yes, I would like to use the bela codec and
case a): Process the streamed stereo audio coming in from the bluetooth on the bela, then send it via Bela audio out,
case b): Enable calling via bluetooth, i.e., processing a mono audio stream coming in via bluetooth, and a microphone input via analog audio in on bela, then sending the mix via audio out and, also, the microphone signal out via bluetooth.
Depending on your application, Bluetooth latency might be an inherent issue.
I have yet to see audio Bluetooth that provides anything close to the latencies a musician could use in real time. Bt for playback of a of previously recorded streams is fine, but nothing where you are interactively creating the sound and monitoring it
najan Hi - did you ever get this to work on the Bela mini?
I want to use the second PRU to create an in-series I2S out/in on the bela mini to create a sort of effect send/return loop that can delegate to a second chipset (like a dedicated M4 for instance). Also currently struggling a bit getting my head around the pin addresses ...
adriaan I want to use the second PRU to create an in-series I2S out/in on the bela mini to create a sort of effect send/return loop that can delegate to a second chipset (like a dedicated M4 for instance).
You wouldn't necessarily need a separate PRU. You would probably be better off just adding I/O ports to the current McASP configuration, or move from using two channels per data line to having 16 channels (the way it's done on the CTAG BEAST), which is compatible with Bela Mini codec's "256-clock mode". In the second case you'd need the M4 (or whatever your external device is) to be able to handle a TDM stream (instead of I2S).
giuliomoro Thanks for this! (sorry I only noticed your reply now)
I do want to stick with a dedicated I2S, because the second board will have to interact with other 3rd party hardware, and I2S seems to be a well adopted format. Basically, we want to use the Bela for its ADC & DCA (and some sensors via I2C) as a test harness & dev platform.
Also very interested to figure out how everything's connected, so getting the seconds PRU up & running is a good exercise.
adriaan I do want to stick with a dedicated I2S, because the second board will have to interact with other 3rd party hardware, and I2S seems to be a well adopted format.
The best option is still to use other data channels of the McASP. There are up to 4 data channels on each McASP, each of which can be an input or an output. The format (I2S vs TDM) will be the same for all the channels. So if using the codec in I2S mode on two data channels (one for input one for output), you can use another two channels (one for input, one for output) in I2S mode.
giuliomoro Ah ok, thanks - I'll have a look into this.
Presumably the code I load onto PRU0 will have to retain the existing functionality, or I'll lose audio input/output altogether, or are you saying this is possible through config only?
If it's the former, is this the right code to base my changes on: /root/Bela/pru/pru_rtaudio.p
?
There would be only one PRU running and it would feed the McASP 2x the amount of data. The McASP would then split that data across the 2x as many data lines. It's best to start from pru_rtaudio_irq.p
because it has the McASP FIFOs enabled. That is quite some work, however. We have an in-house solution for this which works great but it took weeks of work to get there.
Dear list,
Is there a straight forward tutorial/guide to implement an I2S microphone on Bela mini yet? The (ultra) small form factor of the microphone is essential in the project I am working on as is the small form factor of the mini bela itself. The microphone would be working as a gate but also for pitch detection.
Context:
I had this running as an analogue solution on a pocketbeagle using an analogue input on that board utilizing the PRU, but the large difference in volume between noise and sinusoidal sounds on my instrument could not be handled by the limited bit depth of these inputs (and large bit noise on the lower bits). Plus, the piezo microphone I used took too much of the surrounding sound to properly work as a gate especially when using soft noisy sounds. The idea is to put the microphone closer to the source (trumpet lead pipe) and as such make it much smaller.
Best and thanks, Hans.
What's the distance between the microphone and the BelaMini? Anything more than a few cm may have signal quality issues if you are trying using I2S.
What is a few centimeters? The objective is to have the Bela very close actually. The microphone will be close to P1.1. I might be able to do it with headers bend in such a way that a super small breakout board with the microphone can be connected to a PCB board directly without wires.
Would you have a recommendation for the microphone considering signal quality? What I think I need for the project is:
Thanks for thinking with me.
Best, Hans.
Electrumpet The microphone will be close to P1.1. I might be able to do it with headers bend in such a way that a super small breakout board with the microphone can be connected to a PCB board directly without wires.
Sounds close enough for I2S. On the Bela side, if you use an I2S microphone you'll need as a preparatory step to apply this patch to /opt/bb.org-overlays
and then do make && make install
and reboot:
diff --git a/src/arm/BB-BELA-00A1.dts b/src/arm/BB-BELA-00A1.dts
index 305e2c3..535f986 100644
--- a/src/arm/BB-BELA-00A1.dts
+++ b/src/arm/BB-BELA-00A1.dts
@@ -20,6 +20,7 @@
target = <&ocp>;
__overlay__ {
P2_26_pinmux { status = "disabled"; };
+ P2_28_pinmux { status = "disabled"; };
P2_30_pinmux { status = "disabled"; };
P2_32_pinmux { status = "disabled"; };
P2_34_pinmux { status = "disabled"; };
@@ -74,6 +75,7 @@
* runtime and manage the conflict with CTAG pins */
/* For AXR0 on P9.30 we do something similar so that it can be used
* for SPI */
+ 0x1a8 0x28 /* mcasp0_axr1, P2_28 | MODE0 | INPUT_NOPUPD */
>;
};
Wire your microphone with the LRCLK/WCLK from P1.33, the BCLK from P1.36, and put the data line into P2.28.
Then you should run your project with the added command line option --board BelaMiniMultiI2s
and you should have 4 inputs and 4 outputs in your project, with the Bela inputs and outputs on channels 0 and 2 and your microphone input on channel 1 or 3. Remaining channels are unused.
I don't have specific microphone recommendations, though, unfortunately, neither I2S or analog output.