AudioPlayer improvements

[seltzdesign]

In an effort not to unnecessarily spam the original topic here: Dancing Polygon regarding AudioPlayer improvements, I am creating this new thread to continue.

It started with a small issue in the tutorial:

@joreg

that sounds like an issue with not matching sample rates between the file and the engine, see:

. the engines sample rate can typically be set with the driver settings. in case of wasapi it may be possible to change this under your System → Sound settings in windows.

Which sparked some questions and starts of solutions:

@seltzdesign

Can you explain why this is an issue in the AudioPlayer in vvvv and not in any other software (that I know of). I can’t remember ever using any other audio player where matching the sample rate would have been an issue. They all just “work”. What are all these other audio players doing that is not possible to do in the gamma AudioPlayer automatically as well?

We use the AudioPlayer in gamma as well and so often there are errors with unmatching sample rates, where the driver settings tries to set a sample rate that isn’t available for that device, sound playing with little cracks and stutters, etc.

I am really curious what makes it so hard.

Problem:

@joreg

the reason for this is that the AudioPlayer does not automatically adapt to the engines sample rate.

And beginnings of a solution:

@sunep

now with recalculated durations

EDIT:
It seems to work pretty well. I made a process and put it in my Github:

GitHub - sunep/vvvv-sunep-modules: Here I keep my collection of little modules that might be relevant for others as well as myself

---

I have tested the improved AudioPlayer and there still seem to be 2 issues (not with your workaround @sunep ), but with AudioPlayer in general.

The first one, which has always stumped me, is that the default in the SampleRate input pin is set to 48.000Hz, which most of the time causes a warning to show that it is not a valid Enum entry:

You can see it’s hard-coded as a default. I think this is wrong and the default should probably be the highest available entry in the enum.

I have tested it with all my audio devices and there is not one that allows anything other than 44.100?! Even my iConnectivity Audio 4 soundcard that supports 96KHz only shows 44.100 when using the Wasapi or ASIO driver. So maybe that is already something that isn’t right.

Also, I am getting a “Index was outside he bounds of the array” error:

Any ideas on those findings?

[seltzdesign]

I tested @sunep’s solution with these test files and it works perfectly:

GitHub - voxserv/audio_quality_testing_samples: Human speech samples for audio quality...

https://helpguide.sony.net/high-res/sample1/v1/en/index.html
https://www.mmsp.ece.mcgill.ca/Documents/AudioFormats/WAVE/Samples.html

I could also coax my soundcard into giving me 96KHz sound, but it had to be done in the settings of the driver. Does a normal soundcard even allow switching of the sample rate using DriverSettings? I have tried with so many different devices and I have never seen one where you can actually switch.

It seems by default it always adds the 48KHz enum for some reason. If I restart vvvv after changing the sample rate in the driver (F9 isn’t enough), then the enum only has the new sample rate.

I’m starting to wander if DriverSettings should even allow for switching of the sample rate. Doesn’t it always at least require restarting vvvv to be applied anyways and should be handled by the driver, ie. the settings of the driver!? It seems like I have to set the sample rate in the driver, restart vvvv and then the enum only contains the new sample rate anyways.

The options shown by the driver vs driver settings in vvvv:

[seltzdesign]

I did some more tests and found a file that exhibits the behavior with the crackling and popping sounds.

If the audio device is set to 48KHz and certain .mp3 files are in 44.1KHz, then only in vvvv you get these popping and crackling sounds when playing back.

Here is a recording of the output with a microphone:

https://vimeo.com/1044656239/c8cc3bd590?share=copy

First I play it in vvvv and you can hear all the pops and crackles, then I play it in VLC and it’s fine. I then switch the audio device to 44.1KHz and it plays back the file just fine.

Here is the file in question:

10 A Child Is Born_96Kbps.zip (2.5 MB)

[sunep]

I also feel that “my” speed adjustment method is quite a bit of a hack, it feels too simple so there is probably a better way of doing it.
I played various files with it and it works. I do mostly have files at sample rates that are multiples of 48kHz in uncompressed or lossless compression formats.

[seltzdesign]

It seems to work great so far. I have tried content from 8KHz all the way to 96KHz and nothing has sounded “wrong” so far :)

I think the bugs with the sample rate selection and crackling sounds sometimes are separate issues, but as for the speed adjustment, that seems to work perfectly!

[sunep]

I can add 192kHz to that, it definitely sounds wrong without the speed adjustment

[joreg]

Just remembered that we do already have a Resample [Audio.Utils] node for those cases. See it’s helppatch. Configure it like this:

Then please test your files and report. We can then probably simply integrate this node in the AudioPlayer.

[ajitid]

@joreg, I played the sample files @seltzdesign gave with Resample node. They all worked fine. (Just for the sake of completeness, I played all but these ones.)

I have a slightly related question: I was playing these mono testaudio seltzdesign shared. I found that if I used ToStereo node so that the audio plays in both of my ears, it sounded differently than if I play in VLC or mpv. Is there a proper way to play monos?

[joreg]

@ajitid

I found that if I used ToStereo node so that the audio plays in both of my ears, it sounded differently than if I play in VLC or mpv. Is there a proper way to play monos?

please try the following:

• delete VL.Audio.Configuration.xml from your C:\Users..\AppData\Local\vvvv\gamma-(preview)
• start vvvv
• repeat your test with both stable and preview to see if there’s a difference
• report your findings

[ajitid]

Thanks @joreg. Turns out it was a logic error: I was converting to stereo before passing it to Resample. Rather, I should have done the opposite, i.e. take the output of Resample+ForEach and pass it to ToStereo node.