Page 1 of 1

Sample rate vs. audio drivers

Posted: February 16th, 2013, 19:04
by quah
I just started playing with the alpha this morning. I love some things about the UI and look forward to seeing where this goes...

I play audio files in many encodings, sample rates, and bit depths. One of the key things I want out of a music player is for it to properly set the sample rate of my audio device to the native sample rate of the file that is currently playing, and to never ever resample or allow Windows to resample.

So far my solution has been to use Foobar 2000 and ASIO drivers to feed my RME Fireface audio interface.

Trying out Resonic Alpha 621, I can see that it is NOT setting the sample rate of my audio device. So a 48kHz file is playing at 44.1kHz on the RME Fireface. (I'm not sure if it is being resampled or just played back slowly.)

On a related note, the player should display the sample rate, bit depth, and channel count of the file currently playing.

Thanks!

Re: Sample rate vs. audio drivers

Posted: February 17th, 2013, 16:41
by Tom
Hey there!

Let me cut right to the point :)

Resonic - not Windows - is currently resampling all audio material to 44.1kHz using a pretty good quality SRC, which seemed like the most compatible approach for the alpha version. And even though there'll be a high-resolution SRC option this won't stay like it is now, of course.

Resonic Pro will come with full ASIO support.

However, there's some general problems with opening the sample format as-is:

The most important one being that opening and closing the soundcard on every single play is very expensive and would have a big impact on overall responsiveness.

Another problem, the soundcard needs to support the native sample format. If it doesn't - and there's lots of soundcards out there that don't - open will fail, in which case the soundcard would need to be opened a second time, with a fallback format, which would usually be 44.1kHz.

You're talking Fireface here. I'm a RME HDSP user myself since day 1 of the Multiface release, currently am on two Multiface II. While RME has likely the best Windows drivers out there they usually only support a few standard sampling rates: 32k, 44.1k, 48k, 88.2k, 96k, and some up to 192k. Everything that falls out of this - which is bound to the driver and soundcard - will fail to play anyways.

There are only very few ASIO drivers that also support lower rates, like the fake-ASIO DirectX Full Duplex driver which can also play 11k and 22k - however, pretty useless.
Trying out Resonic Alpha 621, I can see that it is NOT setting the sample rate of my audio device. So a 48kHz file is playing at 44.1kHz on the RME Fireface. (I'm not sure if it is being resampled or just played back slowly.)
On my DAW system I use a fixed PreSonus HW clock which runs at 48k, i.e. the whole sound system has to run at 48k. In this case Resonic should open up the output at 48k as well. It'll support output frequency selection in one of the upcoming releases, once the preferences dialog is implemented.
On a related note, the player should display the sample rate, bit depth, and channel count of the file currently playing.
All these infos are in the info bar right below the filename at the top of the window. Or are you talking about something else?

Re: Sample rate vs. audio drivers

Posted: February 17th, 2013, 19:19
by quah
Thanks for the prompt and thorough reply, Tom! I do appreciate the difficulties with trying to make this work across so many combinations of files, drivers, hardware.

Perhaps I can help by describing my expectations as a user...

Typically I'm using the player (Resonic in this case) for some critical music listening. These files are almost always 44.1kHz or greater, and always some multiple of 44.1 or 48. If I stumble upon an oddball such as a DAT recording at the long-play 32kHz mode, I'll resample it to something more common in my music editor with a top-quality plug-in.

If Resonic was going to try to handle all cases itself, here is how I would expect it to behave: First time it opens the audio device, it should detect the set of allowable sample rates. It should have a configurable default sample rate also. When playing a file in an unsupported sample rate, it should resample to the default sample rate; otherwise it should play at file rate. Either way, it should change the sample rate on the audio device each time it needs to.

I suspect it all gets more complicated when we consider the conflicts between multiple applications, system sounds, exclusive access, priorities, and the multiple concurrently operating drivers.

I appreciate that, as a music-playing file browser, that it might sometimes be more important to start playing a file instantly than to play it correctly.

I can say this: Foobar 2000 almost always gets it right. However, on my setup it has a big problem when the playlist has files with varying rates. When it gets to a file with a new rate, it just stops. It won't start playing the next file until I hit "play" again. Alone at my desk it is fine, but it makes it hard to use for entertaining or background music.

Why am I looking for an alternative to Foobar 2000? I can't recommend it to my friends because it is too complex. The default configuration is inadequate. The forked development (Columns UI vs. standard) is a mess. The playlist and bookmark system is unpredictable.

I now see the sample rate, bit depth and channel count in the window. Sorry about that.

Thanks!

Re: Sample rate vs. audio drivers

Posted: February 18th, 2013, 02:12
by MaxLapierre
In FL Studio I use ASIO4ALL 2.11 Beta1

Support multiple sample rates concurrently - for as long as they are physically derived from a common master clock, are integer multiples of each other (except 44.1/48kHz special case), etc...

Support a number of sample rates on the ASIO side that the audio device does not physically support. Basically, this means an extension to the on-the-fly rate conversion capabilities.

http://www.asio4all.com/

Re: Sample rate vs. audio drivers

Posted: February 28th, 2013, 15:33
by Tom
quah wrote:If Resonic was going to try to handle all cases itself, here is how I would expect it to behave
That sounds about right. Still, this is very tricky. Because you are most likely talking about a single-sound card setup, like most users have. There are certain cases where output is locked to a fixed sampling rate, for example 48kHz. I'd rather not go into this right now as it's getting too complex very fast and right now I have my priorities with Resonic, but you certainly have a good point. I will revisit this.
I suspect it all gets more complicated when we consider the conflicts between multiple applications, system sounds, exclusive access, priorities, and the multiple concurrently operating drivers.
Exactly. And as I said, as long as there is just one generic multimedia sound card (i.e. onboard sound, Creative devices, etc.) and DirectSound involved, it's pretty easy. Practically a no-go though on ASIO, and not so easy on other audio systems as well.
However, on my setup it has a big problem when the playlist has files with varying rates. When it gets to a file with a new rate, it just stops. It won't start playing the next file until I hit "play" again. Alone at my desk it is fine, but it makes it hard to use for entertaining or background music.
Most likely because it does not automatically reopen the sound driver with that new sampling rate. When you press play again it detects the change and reopens the driver. My guess.

That much being said, in a future release of Resonic I'll add a high-resolution resampling option.
Why am I looking for an alternative to Foobar 2000? I can't recommend it to my friends because it is too complex. The default configuration is inadequate. The forked development (Columns UI vs. standard) is a mess. The playlist and bookmark system is unpredictable.
True that.

Foo in many aspects is excellent, but this and quite a few other quirks made me stop using it years ago. The same with Winamp though, which is pretty senseless for browsing - especially for short sounds and loops.