Time for a new Audiolibrary

Frank B

Senior Member
I'd like to propose a new Audiolibrary.
In a way that the old still exists, but marked as "deprecated".

The new name could be <Audio48> or similar, and more or less a copy of the old, with some important details changed.

- With 44.1kHz we see more and more limitations:

:On Teensy3 (uses 44117.6417Hz), SPDIF is on the upper end of allowed tolerance, and we see problems with USB ("klicks", etc)
ADAT changes the frequency to 44100 without any information and ignores all other parts of the library.

:On Teensy4 (uses 44100Hz) we will run into problems with ADC and PWM. This is partly my fault because a year ago I believed NXP when they said the IMXRT is great for exact timing of audio. Well it is - but not for ADC, PWM or other timers - they just can not run from the Audio PLL. The only _reliable_ chance is to use 44117Hz again (See problems above) -however, a change on this point would mean to create compatibility problems and new problems with new devices like s/pdif-in. I have no idea how to solve that.

Using 48KHz would solve all these problems and create only one new: Existing 44.1kHz encoded wav-files (or mp3) are not compatible anymore and need a re-encoding. This does not hurt.

A "new" library (well, basicially the old one!) would give the chance to change a few things more:
- User-selectable "SD"-library (The one from Bill Greiman is faster)
- Introduce the possibility to use other dataformats (float) later.

I know, _now_ is not the time to do something like this - but it would be good to add it to the "Roadmap" - midterm. We have enough experienced users who can work on this and would like to do it. So PJRC (Paul) does not need to do much - but he should give the OK for this and maybe support it a little bit by answering some questions or decide the details.
 
Last edited:
I wonder if it's actually necessary to have a separate version of the library.

Is there something structural about the current audio library that prevents it from having 48k mode that could be specified at compile time?

At either sample rate the WAV or MP3 reader could include sample-rate conversion which might be made available as a utility function optimized for 44.1k->48k or 48k->44.1k.
 
I wonder if it's actually necessary to have a separate version of the library.

Is there something structural about the current audio library that prevents it from having 48k mode that could be specified at compile time?

-Because it would be a clean cut.
-It does not have to be backwards compatible. The old version will still be there, old programs will still compile without any change.
Edit: - we can drop support for CPUs without floating point support which will make things easier
-I don't see the slightest chance that changes like these would be merged to the existing library. Efforts are there for 4 or 5 years now.
-I'm trying since many years(5+ ?) to get something like per-project #defines (which would allow that easyly). No chance.
Sure, there are ways to do this. But not with a unmodified Arduino-IDE.

Sample-rate conversion:
Without user-accessible compile-time switch:
What would you do with USB, ADAT, SPDIF, ADC ? Automatically switch to 48k? What happens to old programs?
The alternative is to leave it as it is and add these converters for USB, ADAT, SPDIF, too..
What will happen when running this on a teensy 3.2?
 
Last edited:
I am asking myself whether there is a way for sample-rate-conversion from 44117 to 48000 in acceptable audio quality without overloading small Teensy (especially the fixed point MCUs)?

Are there any ideas for this?
 
I wouldn't say samplerate conversion is desirable. It may can be used for some special cases, ok.
However, with a general switch to 48kHz it would'nt be needed. Its easy to convert files on the PC. No need to do that on the Teensy.
 
I am asking myself whether there is a way for sample-rate-conversion from 44117 to 48000 in acceptable audio quality without overloading small Teensy (especially the fixed point MCUs)?

Are there any ideas for this?
That depends on what you mean by "acceptable". :) Simple sample duplication/dropping can sound ok if you aren't too picky (or say you have a tiny speaker and just need it for sound effects.) Linear interpolation is a bit more expensive and sounds a lot better. Keep adding more cycles and more taps to the filter will make it sound better and better.

Even if the library supported either or both 48k or 44.1k hardware rates, there are features and applications that may need sample rate conversion anyway (i.e. play back of low sample rate sound effects at full hardware rates, might be useful), I'm surprised it hasn't come up already.
 
A 48k version of the audio library would be delightful. No SRC please.

Back to poking around to see how far above my paygrade is 48k USB on a T4.0.
 
That depends on what you mean by "acceptable". :) Simple sample duplication/dropping can sound ok if you aren't too picky (or say you have a tiny speaker and just need it for sound effects.) Linear interpolation is a bit more expensive and sounds a lot better.
Doing linear interpolation for my music player to be able to play multiple simultaneous instruments at different frequencies. If I were to implement an audio library, I would design it to be output device sampling rate independent. For example this music player isn't fixed to a single output frequency.

 
That would mean to rewrite _all_ elements. Filters, effects, synths....
The existing "guitar" for example is in a way hardcoded to 44100 that it does not even use the #define for the samplerate and needs a code-change even for 48kHz.
Luckily, most other code uses the #define.

Rewriting all is no fun and I doubt anybody is willing to do that. I can't remember when I got the last PR for my stuff.. 99.9999999% (<- add some "9") of Arduino-"consumers" are not willing to contribute anything. So we need to find a way which is not too much work.
They all have big wish-lists.. I don't see a reason anymore to make these lists shorter (If I dont have some fun doing it). I've learned this in the last years. You'll get nothing back from them.

You'll see on the number of responses on this thread, that the interest is very low anyway.
I'll use my hobby-time for other things. Let others do that if they need it.
 
Last edited:
I'm looking at the Guitar example and don't see where the sample rate is hard coded? I do see a list of note frequencies in Hz, which would stay the same. It uses the AudioSynthKarplusStrong class which seems to correctly use AUDIO_SAMPLE_RATE_EXACT.

I don't have a hardware to test it right now, but I suspect that creating a compile-time option for a 48k sample rate version of the existing library wouldn't be a huge effort.
 
I've got my hand up for a 48 Khz Audio library.


I'm using a Win7 host managing a bunch of Synth gear and audio-wise have a Presonus Audiobox 1818VSL and a Behringer ADA8200 ADAT. To get the best out of the audio department I need to run it at 48 Khz. This means that the SPDIF IN and OUT of the Audiobox use 48Khz clock. I've added a couple of cheap boxes, SPDIF > Analog and Analog > SPDIF. The SPDIF > Analog item auto-senses clock. The Analog>SPDIF item however is fixed at 48Khz. In evaluating the particular device, I discovered that it had poor noise floor. The culprit was the lack of appropriate bypass C on it's 3.3v LDO output. Fixed, a cap was kludged into place.


In regards to a potential 48 Khz Teensy Audio library, either or both of the above cheap boxes could be used here allowing for example, a T4 based Synth outputting via 48Khz SPDIF into say an Audiobox 1818 - galvanically isolated if you work at it or, galvanically isolated Audio in via Optical SPDIF into T4 Usb project.


Food for thought?
 
My vote for 48kHz, with the addition of choice, between 44.1 or 48, or even 32kHz.

ADAT would be much easier to run, more compatible. Not all devices accept always 44.1kHz, and if, then expect S/MUX or bit-splitting, which complicates an ADAT block.

USB audio actually has 48kHz as kind of an established/evolved minimal standard, while 44.1kHz actually does not work always.

See ASIO.
See WASAPI.

It could also be an idea, to have two frequency domains, one for peripheral I/O and one for internal, so calculations could be done with higher resolution on the time axis, or with more relaxed/economic speed and data-flow, while maintaining I/O compatibility.

For this, a resampling block as interface would be necessary.

Also, if doing 44.1kHz, then keep it exact!
For the S/PDIF or music/mp3 and compatibility to the mainstream audio world, it would be useful to offer 44.1kHz as well.

Now, with T4.x coming up and T4.0 maturing, it is a good time to cut out old braids and leave T3.x behind at a working status quo, instead of risking newly created incompatibilities. See even audio memory, which could use more on T4 internally than possible on T3 with available (=non hypothetic/exotic) add-ons.

I am workig my way through ADAT and resampling, etc. but learning curve has reached a step... no ladders, no earthquake... cold hands...
 
You know, that (at least vor T4) can still set the frequency in the core ? At least for T4 this works good. You can choose any fixed standard frequency you want.
My proposal was to use a single frequency - as it is now. Just 48k instead 44.1.
I doubt anyone will work on a lib with flexible samplerate. It's too much work. And I doubt Paul would merge it.

I read a lot of wishes here in this thread, all with a bad "amount of work" / "usefulness" ratio.

My propsal was doable, but all these extensions are not (in a limited time)

Over and out :)
 
a compile-time option for a 48k sample rate version of the existing library wouldn't be a huge effort.

Frequencies and relations are hardcoded according 44.1someting kHZ up now, so all thede parts would have to be adapted.
Also, I'definitely avoid making a hard-code compile-time option, because that would block the road to further enhancements or flexibility. I think T4 could handle dynamic samplerate bus frequencies. It has incredible power compared to T3.6.

I am working on a vocoder block and an ADAT block (which gives me a harder time because of DMA and cache).
T4 just rocks it and has CPU time left. So, I'd say, no need to hardcode.
 
No, only a few things are hardcoded to 44100 (T4). I guess 95% uses the macro for the samplerate.
ADAT is hardcoded (in a very bad way - does not work on T4, anyway). The guitar. USB Audio. WAV. Maybe a few more.. at the moment I'm not aware of any other.
 
Hello,

I think I can assist. I intend to use T4 for a very simply 8i8o USB interface running at 48kHz, probably using the CS42448 via TDM through the iMXRT1062 SAI1 interface. No effects, no volume control, no processing ... just clock the samples in and clock them out. I have enough experience building my own PCB's and have done a couple of successful XMOS designs so I'm happy to give this a shot.

Looking through the existing TD 1.52beta audio codebase it looks like a lot of the infrastructure is already there (well done PJRC!), so with a bunch of additions and modifications and makefile switches it might be possible to neatly fit this into the existing codebase without breaking existing projects @44.1k.

Given that this thread is for 'A New Audio Library' I might just go ahead and do a fresh post to track this work.

Cheers, T
 
Based on all the great info here on the forum, my floating-point re-write of the Audio Library has both a user configurable sample rate and a user configurable block size (less than or equal to 128).

https://github.com/Tympan/Tympan_Library

The pure-DSP audio processing blocks were quite easy to port over to be flexible with sample rate and blocksize. It was the hardware-interacting classes that were harder. Once I got I2S working, that took care of a lot of hardware. SD writing and FFT operations took a little bit of thought along with a few constraints on the human programmer (like, the FFT block size must be 2x or 4x the blocksize).

Where I had to admit defeat is with the USB Audio class. Wow. Also, most of the other hardware classes (ADAT, for example) haven't even been attempted because I had no use for them. But, with so many of the other classes ported over, the scope for a switch to 48 kHz (or 96 kHz or whatever) has been reduced, which perhaps makes it approachable.

Chip
 
Oh, and I was surprised by the concern over what to do about resampling WAV files that are in 44.1kHz when you want them to be in 48 kHz. I mean, resampling is noble, but the current audio library doesn't resample everything to 44.1kHz, so why worry about it in your 48 kHz version of the library?

If you're running 48kHz and you're asking to play a 44.1kHz file, there are two easy choices:

1) Decline to play the file and issue an error (like the current Audio library)
2) Ignore the file's sample rate and play it 48 kHz (which might be preferable)

Either one is easy.

If you're a super nice person, you could indeed write an audio processing block to do resampling between 44.1 and 48, but I don't see it as a necessary thing to do.

Chip
 
I've read about the concern over non-FP MCUs, like 3.2 etc.

From what I've gathered, PJRC plans to bring to market a full family of 4.x Teensies: 4.0 ("ala 3.2"), 4.1 ("ala 3.6") and a future even cheaper "4LC", if I remember well.
So maybe, when thinking about a new Audio Library, we could aim for 3.5 + 3.6 + 4.x family only, without 3.2/LC compatibility. So we can count on FP, fast clock, more memory, and streamline the code.
 
Agreed.
Sadly, common interest is much too low.
If I need it, i'll write my own code, for my own use. Done. Since I don't need all the effects etc. this is done in a few minutes. At this point I can also replace the SD library with something faster.
 
Back
Top