Support arbitrary bit-depth and sample-rate processing.

[Sean M. Pappalardo]

If only for marketing reasons, and for studio use, it would be fun to extend our mixing engine to work with 24-bit (integer) and 32-bit float samples at sample rates up to and including 192kHz.

This would actually be useful since WAV and FLAC both support 32-bit float samples and up to 192kHz sample rates. (FLAC goes as high as 655.35kHz!)

But it should be selectable, and default to 16-bit, 48kHz (or whatever it is currently,) so people that don't need that level of quality won't waste the resources on it (and Mixxx can still run on lower powered hardware.)

[William Good (bkgood)]

CachingReader on up (in the engine call path) all uses 32-bit floats. Having the SoundSource's just write floats to memory instead of int16's would allow all the decoders to write to the precisions which their corresponding formats support, and would have no real affect on performance, with the only real downside being minor duplication of code in SoundSource's (because most will be doing an int16 to float32 conversion, but there is a method in SampleUtil accomplishing this which CachingReader currently uses to do the job). The SoundSource interface needs updating anyway, with brilliance like `unsigned read(unsigned long size, const SAMPLE *dest)'... yeah, because a destination buffer should obviously be const. /sarcasm

This might be more important in input (since most digital audio is made available as 16-bit CD-Audio anyway...), as all our input is int16 (because that's what xwax wants) but once passthrough gets done it'd be useful to support the 24-bit input many cards support these days. We'd just have to convert from float32 or int32 or whatever to int16 for xwax.

[Uwe Klotz (uklotzde-deactivatedaccount)]

The 1st step towards this goal:
https://github.com/mixxxdj/mixxx/pull/754

[RJ Skerry-Ryan (rryan)]

What's the status on this? Should we target to a milestone or mark not-in-progress?

[Daniel Schürmann (daschuer)]

Isn't it already completely done?
We originally had a bottle neck In the SoundSource code.

[RJ Skerry-Ryan (rryan)]

Maybe? That's why I'm asking :)

Being able to read any audio file without loss of fidelity is one part of the problem, but I think this bug is about the mixing engine, not the audio file decoding.

If I can re-phrase what Sean wanted:
- The ability to run the mixing engine at any sample rate (not just the output sample rate), with a downsampling at the last step to feed samples to the audio interface.
- The ability to run the mixing engine at higher quality than 32-bit float. (e.g. 64-bit or 128-bit float).

(I'm not convinced we need either of these really... thoughts?)

As for the "for marketing purposes" aspect of this bug, I'd much rather we advocate for people understanding what these numbers mean and knowing when higher sample rate is pointless psychoacoustically :)
https://people.xiph.org/~xiphmont/demo/neil-young.html

[Be (be.ing)]

> I'm not convinced we need either of these really... thoughts?

I agree. However, it would be nice to let users select any sample rate supported by their audio interface. Currently we have a hardcoded list of 44.1 kHz, 48 kHz, and 96 kHz. An old comment in the code from 2010 says this is because enumerating supported sample rates is really slow with ALSA:
https://github.com/mixxxdj/mixxx/blob/master/src/soundio/soundmanager.cpp#L84

> As for the "for marketing purposes" aspect of this bug, I'd much rather we advocate for people understanding what these numbers mean and knowing when higher sample rate is pointless psychoacoustically :)
https://people.xiph.org/~xiphmont/demo/neil-young.html

+1

[Daniel Schürmann (daschuer)]

Ok than let's set this to won't fix.
In our FOSS project, there is no need to use pointless marketing tricks.

We should on the other hand support all recording and playback formats, to not be blamed as a bottle neck. Do we have soundcards with a higher resolution than we support?

[Daniel Schürmann (daschuer)]

This can be tracked in a separate bug.

[Swiftb0y (swiftb0y)]

Mixxx now uses GitHub for bug tracking. This bug has been migrated to:
https://github.com/mixxxdj/mixxx/issues/5949