USB interface for multi channel outputs, not just stereo

I tried some more, and it looks like this is quite hard to debug.

I settled on the minimal testing setup, where I just go to the audio settings page on the mac and check if I get a signal at all. This will only get 2 channels at most I think but still shows if it is fundamentally broken.

As said, it works on the Mac where I compiled the sketch:
Intel Core i5, 2016
MacBookPro13,1
10.14.6
-> can record multi-channel audio
-> coreaudiod cpu 1.5% when recording from usb vs 4.5% when recording from internal mic (!)
- BUT I just had a 20 minutes period where it stopped working, until I recompiled and re-uploaded the sketch

It didn't work on any of the other Macs I tried so far

Apple M2 2022
Mac14,7
15.3.1
-> shows as 8 channel device in Audio-Midi-Setup
-> no audio coming into QT PLayer
-> coreaudiod cpu 10% regardless of selected input device (not exactly sure what the 100% baseline is)

Intel core 2013 something
10.14
- shows up as 8 channel device, but no signal
- this is surprising because it is a similar system like the one where it works.

Next I tried to understand if the sketch is actually running on the teensy.
For this I had to comment out the "sgtl5000.setAddress(HIGH)" in order to hear the signal on one ear of the analog output.

Only on the Mac where recording worked, the sketch seems to run properly.
More interestingly, when just powering the teensy with a usb power bar, there is no signal coming out of the analog output. So it looks like it needs a working communication with a receiving device and otherwise gets stuck. Is this intrinsic in your usb-audio implementation, or just a property of the example sketch? Maybe the implementation is fragile and craps out if there is a hickup in the communication?
For my use case, I mostly want to run the teensy without a computer, and only occasionally connect it to a computer to record via USB. WIth the stock USB audio implementation this was never an issue.

Happy to continue testing tonight!
 
Weiweiweiwear said:
Big thanks to @alex6679 for all the helps, we have met twice for last two saturdays, unfortunately we still could not spot the reason why my Mac could not work with teensy 4.1 for USB multi-channels. In the beginning I was on OS Ventura (13.x.x) and then updated to Sequoia (15.0.1).

I am posting the screenshots of the spec of my USB and Mac OS here for further debugging and really looking for mac users who can share their experience if they have made it work. cheers.

View attachment 36078View attachment 36079
Click to expand...
Hi hi this is my Mac spec i posted.

@electricat sorry did you mean you can find the Teensy and CS42448 board as audio device in DAW and can output 8 channels in real-time? or just record the outputs from teensy and CS42448 as standalone SD player? are you also on intel chip? thanks.
 
Weiweiweiwear said:
@electricat sorry did you mean you can find the Teensy and CS42448 board as audio device in DAW and can output 8 channels in real-time? or just record the outputs from teensy and CS42448 as standalone SD player? are you also on intel chip? thanks.
Click to expand...

On 2 out of 3 Macs I tried I don't have a DAW installed. I just went to the 'Audio' panel in the system settings, and checked if the teensy appears and if I get a signal. So far I only looked at the output from the teensy as the audio input into the Mac, not the other way around. I used the USBmultiChannelTest which sends a bunch of triangle waves on the different channels.
On all 3 Macs the device appears as "Teensy Midi/Audio" and reports 8in/8out.
Only on one of the Macs I actually got a signal. This one is intel, yes. But one of the Macs where it doesn't work is also Intel based.
 
A, I see the sketch is waiting for Serial in an infinite loop, I guess that explains why it doesn't work on any system that does not have the Arduino IDE running!

This if course would change all the conclusions I made. Will have to do the testing again then...
 
Yes, sorry, I have a tendency to put the infinite serial wait in debug code, because you can easily miss early output without it. And my “everyday” audio adaptor has had its I2C address changed, and again I forget and leave it in…
 
@electricat Thanks for the tests.
More interestingly, when just powering the teensy with a usb power bar, there is no signal coming out of the analog output. So it looks like it needs a working communication with a receiving device and otherwise gets stuck. Is this intrinsic in your usb-audio implementation, or just a property of the example sketch? Maybe the implementation is fragile and craps out if there is a hickup in the communication?
Click to expand...
@h4yn0nnym0u5e implemented the example sketch with the sgtl5000. Generally, there shouldn’t be any issues if no USB host is connected to the Teensy and I assume this behaviour is specific to the sketch.
I’ve just committed an update to my usb output example (without the SGTL5000). If USB output still isn’t working after removing while(!Serial), I recommend trying this updated example. It also generates triangle wave signals and sends them to the host, but it’s a simpler implementation with fewer potential failure points.
Additionally, this example prints the USB output status every two seconds, providing more insight in case of issues. To view the status updates on a Mac, you’ll need to use the Arduino Serial Monitor.
 
Ok, I tried again on the 4 Macs in the house, and this time everything seems to work fine (Had to remove the infinite serial wait). I could receive audio on all machines. On 2 machines with a DAW installed, I could verify that all 8 audio channels are received, and I could send audio to the teensy via any of the 8 channels and have it loop-backed on the analog output.

2 of the machines were Arm with MacOS 15.3, 2 Intel with 10.14

Anything else I can test? Looks like I am not affected by the specific issue you are investigating, right?
 
That’s kind of good news, though it doesn’t help us pin down what the heck is happening to @Weiweiweiwear :confused: But thank you for taking the time, it does show that 6/7 of Macs are OK!

Could I plead with you to try and find out the Apple product code for each of the machines you tried? My iPhone 13, for example, is Model Number FLQ63B/A, as found in Settings/General/About, or A2633 if I tap on the model number. My iPad is A2072 (in very small text on the back…) or FYH62B/A. If nothing else, it’ll reassure people with that exact model that the code should work for them, and also mean we don’t necessarily need anyone else to test those models again, unless they have a different MacOS version on them.

Thanks again, much appreciated
 
Last edited:
These are the machines I tried:
- MacBook Air, Mac15,13, MRYR3SM/A , MacOS 15.3 (audio in both direction works)
- MacBook Pro, MacBookPro13, (no model number), MacOS 10.14 (audio in both direction works)
- MacBook Pro, Mac14,7, Z16U000RFSM/A, MacOS 15.3 (only tested audio from teensy to Mac on 2 channels, works)
- MacBook Pro, MacBookPro11,1, (no model number), MacOS 10.14, (only tested audio from teensy to Mac on 2 channels, works)
 
Thanks for testing. On the one hand, I’m glad that the USB interface works for all your Macs. On the other hand, it's still a mystery why it’s not working for Weiweiweiwear. I guess we have to wait until somebody can reproduce the problem on another Mac.
 
good to hear that! but I did the test with @alex6679 via video chat step by step with his code so it’s very unlikely I did something wrong there. And back then it was not only not working on my MacBook Pro but also not on another Mac Book Pro of my friends, that’s why I thought it’s helpless, attached photo is the spec of his mac.

@electricat

Thank you for the tests on mac ARM and Intel both. Just to clarify how exactly your setup and protocol there was.

So mine was:
1. Teensy 4.1 was wired to CS42448 via I2S.
2. Teensy 4.1 was connected to my MacBook Pro (tried both usb C and A).
3. Select teensy audio/midi as sound card in my DAW (max/msp).
4. Play a sine wave in DAW and output it in Chanel 1 and 2.
5. Expecting real-time sound from the speakers (in my case the 1-second audio and the break).

Is this your protocol too?

I can soon buy a new MacBook Pro or Mac mini with M4 ARM structure too and i assume it will work for me?
 

Attachments

  • 3BE4E491-3768-4E63-853A-5B3A8451238B.jpeg
    3BE4E491-3768-4E63-853A-5B3A8451238B.jpeg
    46.3 KB · Views: 26
Last edited:
Weiweiweiwear said:
1. Teensy 4.1 was wired to CS42448 via I2S.
Click to expand...
I've never used a CS42448 in I²S mode, not 100% sure what happens. It shouldn't matter, except that presumably you'd only get 2 channels working because it's only a stereo protocol. TDM is the way to go really. Does the Audio library control_CS42448 even support I²S?
Weiweiweiwear said:
I can soon buy a new MacBook Pro or Mac mini with M4 ARM structure too and i assume it will work for me?
Click to expand...
The signs from others' testing are good, but then your friend's also-non-working Mac is not so good. Google Translate says "China" when it looks at his spec ... some odd regional thing, possibly? I'm clutching at straws again here, there's no reason at all why where you live should affect the audio drivers!

I certainly wouldn't lay out money on an assumption that a new Mac will make it work ... unless I could return it if it doesn't.
 
Hi, I don't really know what the CS42448 is. A DAC chip?

My test setup was:
- Teensy 4.1. connected to teensy audio board via I2S
- Teensy connected to Mac via USB
- Select teensy MIDI/Audio as audio interface in DAW (Reaper)
- receiving audio from the teensy in an audio track on the DAW, and sending that track to the teensy
- selecting several different audio channels 1 to 8 both for the incoming signal into the DAW, and the outgoing one
- so I was simultaneously testing audio from and to the teensy
- I could hear the different triangle waves in the right ear of the analog out of the teensy audio board
 
Yup, the CS42448 is a 6i8o codec - it can have an external chip added to bring it up to 8i8o. Apart from the fact that it's now obsolete, it makes a good match for the multi-channel USB :giggle: but my demo was based on the Teensy audio adaptor, as being more likely to be available. You should I think have heard a constant 220Hz tone on the left ear, same as what's going from Teensy to Mac over the USB.
 
Last edited:
Sorry, I haven't read the entire thread very carefully, but I understood that the issue is with the usb-audio only and independent from what DAC is connected or used.

My use case: I am building a 'groove box' (synthesizer, drumcomputer and sequencer in one box). It has 6 tracks. Usually one is listening through the stereo output. But at some point in the creative process, it is common/convenient to export all tracks individually to a DAW, where one can put effects, do additional editing, arranging, mixing, etc. For this, multi-track usb audio is perfect. Using the 8 tracks of Alex' usb implementation I an send the stereo mix for reference plus the 6 individual tracks all at the same time.
For now I am not using any audio input into the teensy (usb or analog), all sounds are synthesized, it is not a sampler.

I integrated the new usb implementation with my code a couple of days ago, and it seems to work great. I still need to check, if this is costing some processing power on the teensy (I am already squeezed for cpu due to all the audio processing). But so far it looks great.
So thanks a lot to Alex and everybody who helped pulling this off!
 
It should be independent of the codec in use … but maybe not? @Weiweiweiwear, could you try your code using AudioOutputI2SOct in place of the TDM? No need for actual hardware, you should just get the first two channels on your Teensy audio adaptor, which I think you said above is OK.
 
When I need to debug a sketch, I like to implement a minimum example that allows me to reproduce the problem. In case of the usb interface, I would use the two very simple examples main_usbInput.ino and main_usbOutput.ino. They rule out that there is a problem with the codec. Also, they provide additional information like if there are buffer over- or underruns and in case of the usb input, if any signal is sent from the host to the Teensy.
When we debugged @Weiweiweiwear's problem, we mostly used the main_usbInput.ino example and I am therefore sure that it is not a problem of the codec. Also, we mostly tested the 2 channel, 44.1kHz and 16bit configuration in order to rule that the problem is related to multi-channel audio.
@Weiweiweiwear when you tested the usb interface on your friends's Mac, can it be that it didn't work because of a 'while(!Serial)' statement in the setup function? Do you remember which sketch you tested and if you opened a Serial monitor on your friend's Mac?
 
That makes sense. Your simple examples do “use” AudioOutputI2S, but only to provide update responsibility, so that eliminates the CS42448 or use of TDM as the culprit.
 
alex6679 said:
When I need to debug a sketch, I like to implement a minimum example that allows me to reproduce the problem. In case of the usb interface, I would use the two very simple examples main_usbInput.ino and main_usbOutput.ino. They rule out that there is a problem with the codec. Also, they provide additional information like if there are buffer over- or underruns and in case of the usb input, if any signal is sent from the host to the Teensy.
When we debugged @Weiweiweiwear's problem, we mostly used the main_usbInput.ino example and I am therefore sure that it is not a problem of the codec. Also, we mostly tested the 2 channel, 44.1kHz and 16bit configuration in order to rule that the problem is related to multi-channel audio.
@Weiweiweiwear when you tested the usb interface on your friends's Mac, can it be that it didn't work because of a 'while(!Serial)' statement in the setup function? Do you remember which sketch you tested and if you opened a Serial monitor on your friend's Mac?
Click to expand...

Hi @alex6679 I've been using this branch of yours for the testing. I was using AudioOutputTDM (see the .ino code below) as I told you in private conversation, should I try AudioOutputI2S? or may I know the full code? thank you so much.

@electricat I just realized you weren't on CS42448, is it make sense to get a CS42448 board there and test it with your Mac in parallel?

#include <Audio.h>
#include <Wire.h>
#include <SPI.h>
#include <SD.h>
#include <SerialFlash.h>
// GUItool: begin automatically generated code
AudioInputUSBOct usb_oct1; //xy=517,222
AudioOutputTDM tdm1; //xy=836,257
AudioConnection patchCord1(usb_oct1, 0, tdm1, 0);
AudioConnection patchCord2(usb_oct1, 1, tdm1, 2);
AudioConnection patchCord3(usb_oct1, 2, tdm1, 4);
AudioConnection patchCord4(usb_oct1, 3, tdm1, 6);
AudioConnection patchCord5(usb_oct1, 4, tdm1, 8);
AudioConnection patchCord6(usb_oct1, 5, tdm1, 10);
AudioConnection patchCord7(usb_oct1, 6, tdm1, 12);
AudioConnection patchCord8(usb_oct1, 7, tdm1, 14);
AudioControlCS42448 cs42448_1; //xy=415,439
// GUItool: end automatically generated code
void setup() {
AudioMemory(50);
if (cs42448_1.enable() && cs42448_1.volume(0.8)) {
Serial.println("configured CS42448_1");
} else {
Serial.println("failed to config CS42448_1");
}
}
void loop() {
}
 
Unfortunatelly, I can't help you with the CS42448 and I don't know how it behaves if you switch from AudioOutputTDM to AudioOutputI2S. Have you used the CS42448 succefully with the Teensy? Maybe with the current stereo usb interface? If yes, then I recommend to use the sketch that is working and only exchange the usb interface with my code.
You can also switch back to the main branch. I fixed the feedback_accumulator to the default value on the branch you tested. I thought that maybe some invalid feedback is send from Teensy to the Mac that causes the problem. However, the feedback doesn't seem to be the problem.
 
You must log in or register to reply here.
Back
Top