palmerr

I have already done that https://www.pjrc.com/audiotoy-8x8-channel-audio-mixer/ There's an EPS32 in the top RH corner which commands the Teensy via a serial connection, and communicates with another ESP32 TFT touchscreen remote controller. The...

Thanks Shawn, I'm still keen to remove the need for a main loop call, and also to 'defeat' delay(). I'm playing with attaching to the eventResponder at the moment, but have hit a roadblock as the object owning the callback (and its variables)...

I don't think PTP will help improve sound much and its a lot of extra coding to realign packets from all streams. I've found, so far, that a 100Mb ethernet switch not carrying much other traffic and especially ***NOT*** wireless traffic...

Yes, that's two possible uses. Beware, however that network audio from multiple sources without PTP suffers from variable latency - I'm experiencing up to 2.9mS between sources on my test hookup (which is on a private network, so probably...

:-)

Thanks - I'll ponder the options. Standard Teensy Audio practice is to hide the regular loop calls. While testing, I'm using an explicit call in the main loop to avoid yet another complexity! On a different note, a possibly dumb question: which...

Thanks. I'll continue to post progress here

I can try that with some semaphores in the update() code to provide protection against both routines trying to manipulate queue at the same time. Something in the main loop isn't pretty, but EventResponder looks promising to resolve that. Extra...

OK, It's not good practice to call Teensy audio library update functions from the main loop as they need to be sequentially called when a new audio buffer is required for processing - hence the regular software interrupt. I'll have a think about...

Shawn, I've run into a snag... getting this error when calling QNEthernet routines from within a software interrupt (Teensy Audio Library uses them for its regular updating)...

RTMS, The old github repository at ether_audio and id discussed in forum. The discussion on the revised version is at forum. I'll be posting on the latter thread with updates. I haven't priced the completed boards, but will post here when I...

Rich, I'm between a messy board and the final prototype(s) PCBs at the moment. The main PCB is 3" x 5.25" (75 x 130mm). The big red X marks on the schematics are to tell the PCBA folks not to mount these components. I've created some IO 'wing'...

Shawn, I've been thinking about the same issue. If it were just peeking deeper into the queue, then access to the internals would be useful. For my application, with multiple, asynchronous UDP packet streams, a linked list is a better data...

Thanks Shawn, I have read the readme and probed lightly into the code. Queued packets will be very useful for managing any incoming packet overruns at the UDP layer, meaning I can do all my processing with synchronous calls. There can be...

Shawn, Thanks for the info. I had simply assumed that AsyncUDP was directly interrupt driven, rather than the lambda function polling for packets. So I assumed that I was going to have to deal with queue management from both update() and an...

Mike, I'm in the process of updating the library to run with T4.1 native ethernet and shifting to VBAN packets so that multi-channel audio is available to and from desktop PCs. New Ethernet Audio thread

With asynchronous incoming packets I need to ensure the packet queue is not corrupted by interrupt-driven events occurring during update() cycles. Is cli( ) / sei( ) the best approach, or is there a less global interrupt that can be temporarily...

I'm reworking my 2019 Ethernet Audio Library (old Ethernet Audio Library thread and Library) to take advantage of T4.1 native ethernet and to align the UDP packet protocol with what's being used by other products. While there are a large number...

Yay! Done.

Rich, Thanks for your interest. Simple, there's a third sheet to the schematic! The circuits for IC3&4 are identical to 1&2, so I didn't include page 3 for the purposes of the discussion needed at that point. It turned out that it was a code...

Now that TDM input is fixed for odd channels (see Audio lib PRs 440 and 480), a second tranche of boards has been ordered for testing in 16x16 mode, with mappable DI and DO pins for even further expansion, for final testing before going to the...

OK, that's workable. Looks like we've got 6x16 audio channels possible. That's a lot of buffers, particularly if there's some processing involved! Both SAIs churning through 16 ins and 16 outs is probably enough for anything likely to be...

OK, I'll do that at some point. Now that I have the TDM in and out working, I want to keep testing functionality on a stable software base while I finish the Rev B hardware. I'm working on having it PCBA after the next revision, as I'm tired of...

jMarsh, You are quite correct, I miscopied a partially edited piece of code from Paul's original version. It should read. static void memcpy_tdm_rx(uint32_t *dest1, uint32_t *dest2, const uint32_t *src) { uint32_t i, in1, in2; for (i=0...

The CS42448 uses 32-bit TDM slots and the 3104/3105 chips use 16-bit slots. It appears that the audio library code assumes this and does some 'special' data juggling to put the 32-bit data into alternate audio-library buffer slots. The relevant...

JayShoe, I must have missed something when reading the 3105 datasheet. How are the different I2C addresses selected? My choice of the 3104 was for the differential inputs, as I do a lot of pro audio work where that's essential. On the 3104 I've...

Thanks, I wrote almost the same code today, however it didn't fix my problem (in the other 8x8 Audio update thread) as I had already inverted BCLK in hardware. It did prove, however, that the hardware inverted clock was equivalent to the...

Yes, your calculation of the pole frequency is correct. CODECs oversample at 128 or 256 times Fs and single pole filters start to roll off at 1/10 of the corner frequency, so an antialiasing filter is usually set at around 10x the maximum...

Paul, I'm also working on this with a 4 x TLV320AIC3104 (almost identical to the AIC3015) see Updated 8x8 audio Should I also be modifying the RCR2 BCP bit for inputs? I notice in the input_tdm.cpp code you don't set anything in RCR2

The RevA board is working nicely, however there is an input spike at ~21kHz, the magnitude of which is directly proportional to the signal level (at least for inputs from 0.9 FSD to 0.05 FSD). There is no frequency spike on a sine wave output...

Progress: I have populated a Rev A board and have I2C multiplexing working across the four CODECS and am now working on getting the TDM slots properly aligned and enabled for the ADCs and DACs. The programming model for the chip is quite...

The mux needs to be done per board, so the 1:4 mux is a better fit. (TCA/PCA 9543/4). It is bigger than the tiny TSSOP-10 analog mux I'm using currently and the wiring is more complex (individual SDA/SCL and resistors for each chip) than the mux...

Thanks for the thought about the I2C mux. I simply didn't think of it! I'll see if there's a 4way version available, as it will save some Teensy pins and be a more elegant solution, overall. I've left enough overhang space on the PCB for a T4.1...

h4yn0nnym0u5e, This particular TLV chip has no I2C address lines, so I decode the I2C SCK line on each board with a 2:4 analogue mux. The enable pin on the mux is driven by a Teensy pin - with a jumper to differentiate between the Boards. That...

Folks, With the CS42448 going end of life, I'm updating my 8x8 audio hardware (Audio Toy) and drivers to use multiple TLV320AIC3104 chips (4 per board). These CODECs pay proper attention to TDM transmission, having settings to enter 256...