h4yn0nnym0u5e
Well-known member
That sounds good. We probably need to make sure there are some suitable examples, and a bit of documentation, but apart from that I’m pretty confident it’s ready to go.
USB interface for multi channel outputs, not just stereo
- Thread starter sonaben
- Start date
h4yn0nnym0u5e
Well-known member
Does this mean that multichannel USB audio is going to be part of the new 1.61 release? If so that's huge!
What is the interface that is planned for this? Will there be 4x4 and 8x8 usb audio objects in the Audio Library?
Last edited:
h4yn0nnym0u5e
Well-known member
Well…
Obviously this is already a month adrift, and not sure if the target date is still the same.
But also
which we haven’t done. @alex6679 , are you OK if I pop together a suitable PR for Paul’s consideration? I’ll probably start with what we have now, plus maybe a couple of really simple examples, say 8 synth waveforms to PC, and 8 PC channels mixed to a stereo I2S output. There’s documentation for the Design Tool: not sure where I’d put more, or what I’d need to add, so maybe that could wait for guidance from @Paul.
Yes, we have added 4-, 6-, and 8-output and -input objects to the library. Just use as before.
In addition, because you need to add a Tools menu entry to select the number of supported USB audio channels, we took the opportunity to add entries for audio sample rate and block size. These obviously default to 44.1kHz and 128 samples, but we’ve tested up to 96kHz and 16 samples. A number of folk want one or both of these, for various reasons, but it does add some complexity so we’ll have to wait and see if Paul approves!
h4yn0nnym0u5e
Well-known member
Sorry, I realise
is a bit misleading. You won’t have to do it yourself - it just has to be added as a standard part of Teensyduino
h4yn0nnym0u5e
Well-known member
I've done a couple of PRs, one for the Audio library and one for cores. It's all still a bit messy because there's no way of doing a PR for the required Tools menu changes, but suitable examples are included as part of the cores PR, and I'm sure Paul will be able to figure them out, or ask if anything's unclear.
PaulStoffregen
Well-known member
Just want to confirm I'm planning to merge this in 1.62 or 1.63.
Immediate plan is to wrap up 1.61 sometime next week.
My immediate plan for 1.62 is upgrading the gcc toolchain from 11.3 to 15.2. First beta for 1.62 will have the new toolchain update with zero library changes from 1.61. Depending on how the toolchain update goes and how much other stuff needs fixing to work with the new toolchain, a 1.62 release might feature only the toolchain and urgent bug fixes, with new features delayed until 1.63. Or if the toolchain looks good early, maybe I can start merging this and a number of other things into 1.62.
Immediate plan is to wrap up 1.61 sometime next week.
My immediate plan for 1.62 is upgrading the gcc toolchain from 11.3 to 15.2. First beta for 1.62 will have the new toolchain update with zero library changes from 1.61. Depending on how the toolchain update goes and how much other stuff needs fixing to work with the new toolchain, a 1.62 release might feature only the toolchain and urgent bug fixes, with new features delayed until 1.63. Or if the toolchain looks good early, maybe I can start merging this and a number of other things into 1.62.
If y'all need any help writing or testing examples I'd be open for this. 8-channel USB audio would be a huge help on an upcoming project.
I have CS42448 based 8x8 hardware I can test with as well as the Platypus 8-Channel.
Is it possible to build working Teensyduino from one of these PRs to get 8x8 audio working before teensy 1.63 release?
h4yn0nnym0u5e
Well-known member
Sure it is. It’s just a bit messy to get set up, but people have been doing it successfully over the couple of years it’s been in development.
The instructions for doing it the old way are in the ReadMe over at https://github.com/alex6679/teensy-4-usbAudio/tree/main, and involve copying a few files into cores, Audio and the Arduino IDE boards / platform files.
You could probably achieve the same effect by using the submitted PRs, which would only involve manually moving the IDE files. I haven’t tested this method, it’s possible I’ve missed something when making the PRs. One thing I do know is a gotcha is that the IDE files are slightly different between 1.x and 2.x; that’s not reflected in the PR files, because Paul will be wanting to make his own decisions on which changes he wants in the Tools menu. I’m hoping for all 3 (USB channel count, audio block size and audio sampling rate).
The way I’ve worked is to fork cores and Audio, and then clone my forks over the top of cores and into the Arduino library folder. That way I can always check out the older branches (or other development branches) as needed.
That’d be great. I’ve done a couple of super-simple ones for the PRs, assuming nothing but an audio adaptor, but TDM ones would also probably be welcome. I think @alex6679 also implemented mute and volume controls - examples for those would be useful, if so. I currently have a bunch of non-audio stuff overflowing my workspace, so no space or time to set up and test that myself.
@h4yn0nnym0u5e Thanks for submitting the pull request.
Right, I added mute and volume controls. It is implemented in a similar way to the current usb audio interface. That means the volume and and mute signals are received by the usb interface, but not directly applied.
Instead the current volume/ mute setting can be polled as shown in this example:
https://github.com/PaulStoffregen/A...wareTesting/PassThroughUSB/PassThroughUSB.ino
Right, I added mute and volume controls. It is implemented in a similar way to the current usb audio interface. That means the volume and and mute signals are received by the usb interface, but not directly applied.
Instead the current volume/ mute setting can be polled as shown in this example:
https://github.com/PaulStoffregen/A...wareTesting/PassThroughUSB/PassThroughUSB.ino
Regarding merging the new usb interface into the core and audio library:
At the new interface, I separated the more complex USB audio functionality from the audio library:
- USBAudioInInterface and USBAudioOutInterface of usb_audio_interface.h/cpp contain the more complex implementation details and do not depend on the audio library. For example, USBAudioInInterface computes the feedback. This means that anyone who wants to use the Teensy USB audio interface without the audio library can directly use these classes.
- AudioInputUSB and AudioOutputUSB, implemented in usb_audio.h and usb_audio.cpp, are intentionally very small and simple. They act only as adapters between USBAudioInInterface / USBAudioOutInterface and the audio library.
Because of this separation, we could move usb_audio.h and usb_audio.cpp from the core to the audio library, keeping the core library leaner.
The compiler will complain that usb_audio.h is missing, but that can easily be fixed by including usb_audio_interface.h instead of usb_audio.h.
@PaulStoffregen @h4yn0nnym0u5e What do you think about that idea?
At the new interface, I separated the more complex USB audio functionality from the audio library:
- USBAudioInInterface and USBAudioOutInterface of usb_audio_interface.h/cpp contain the more complex implementation details and do not depend on the audio library. For example, USBAudioInInterface computes the feedback. This means that anyone who wants to use the Teensy USB audio interface without the audio library can directly use these classes.
- AudioInputUSB and AudioOutputUSB, implemented in usb_audio.h and usb_audio.cpp, are intentionally very small and simple. They act only as adapters between USBAudioInInterface / USBAudioOutInterface and the audio library.
Because of this separation, we could move usb_audio.h and usb_audio.cpp from the core to the audio library, keeping the core library leaner.
The compiler will complain that usb_audio.h is missing, but that can easily be fixed by including usb_audio_interface.h instead of usb_audio.h.
@PaulStoffregen @h4yn0nnym0u5e What do you think about that idea?
h4yn0nnym0u5e
Well-known member
I tend to be of the opinion that "if it ain't broke, don't fix it"! I agree it's messy as-is, but it conforms to the old structure so it looks as close as possible to a simple pull request rather than a re-structuring.
The other major reason to leave it is that this is what multiple users have tested pretty thoroughly by now. Any changes, however minor, make that testing slightly less valid.
On another note, I saw the PR for the incorrect boards.local.txt; this doesn't require any changes to the cores PR, as I made a somewhat improved on which has a 44117.65Hz setting for Teensy 3.x emulation, and also includes settings for the MicroMod.
The other major reason to leave it is that this is what multiple users have tested pretty thoroughly by now. Any changes, however minor, make that testing slightly less valid.
On another note, I saw the PR for the incorrect boards.local.txt; this doesn't require any changes to the cores PR, as I made a somewhat improved on which has a 44117.65Hz setting for Teensy 3.x emulation, and also includes settings for the MicroMod.
h4yn0nnym0u5e
Well-known member
That's a good point against moving stuff from cores to Audio! All the "real" changes made have been in Teensy 4 cores, so will not impact Teensy 3, though of course Teensy 3 users won't be able to benefit, either. The only change within Audio is to implement and document the additional multi-channel USB objects; it'd possibly be worth editing usb_audio.h in the Teensy 3 cores to throw an error if a user tried to make use of them.
Just as all the other audio headers usb_audio.h would be included in Audio.h. Here it can be included only for the T4.0/T4.1 by means of preprocessor conditional. So it would not affect the other Teensys.
I suggested it because there is just no reason for usb_audio.h to be part of the core. Having it in the core is similar to putting e.g. input_spdif3.h in the core instead of the audio library.
But of course, I admit, it's not high priority.
I suggested it because there is just no reason for usb_audio.h to be part of the core. Having it in the core is similar to putting e.g. input_spdif3.h in the core instead of the audio library.
But of course, I admit, it's not high priority.
I checked the boards.local.txt file in the PR and saw that it had already been fixed there. Otherwise, I would have let you know.