JACK doesn't respect data format

[SeeLook]

I noticed that in some cases JACK doesn't start stream with data format different than FLOAT32.
The "cases" occurred when JACK was run in 48000Hz samplerate.
When it was run in 44100Hz, supportedFormats() method returned FLOAT32 and INT16 as well but with 480000 only FLOAT32 was there and stream didn't initialise with INT16.
It happened under Linux.

I didn't test JACK under Mac but there, with coreAudio, supportedFormats() returns only FLOAT32 but RtAudio starts nicely with INT16 and converts it silently.

[garyscavone]

Both JACK and CoreAudio only support Float32 natively. RtAudio should allow a user to read / write the other formats but the “Natively supported data formats” reported by the getDeviceInfo() function / structure will only report the native formats.

Thus, please verify that what you are reporting is different than what I stated above.

—gary

On Feb 27, 2014, at 4:16 AM, SeeLook notifications@github.com wrote:

I noticed that in some cases JACK doesn't start stream with data format different than FLOAT32.
The "cases" occurred when JACK was run in 48000Hz samplerate.
When it was run in 44100Hz, supportedFormats() method returned FLOAT32 and INT16 as well but with 480000 only FLOAT32 was there and stream didn't initialise with INT16.
It happened under Linux.

I didn't test JACK under Mac but there, with coreAudio, supportedFormats() returns only FLOAT32 but RtAudio starts nicely with INT16 and converts it silently.

—
Reply to this email directly or view it on GitHub.

[SeeLook]

I was not able to open a stream with RtAudio JACKAPI and data format set to INT16.
A solution was to open it with FLOAT32.
In my environment (Arch Linux, jack2-dbus) when JACK was started with 44100 - INT16 worked but not with 48000 sample rate.

In fact, it is not big problem to have int to float conversion myself but maybe I can help to find some issue or to expose it for others.

All respects,
SeeLook

[garyscavone]

I just tested this on my own linux system (Fedora 17) and I cannot repeat the behaviour you describe. I started JACK at 48000 and ran the "tests/playsaw.cpp" program for all the different formats listed at the top, and there was no problem. If you run the "tests/audioprobe.cpp" program, it only lists the one sample rate and the one native data format (always 32-bit float for JACK) that the JACK daemon is running at, but the automatic conversion from/to the other supported data formats is still fine.

[SeeLook]

I can't reproduce this issue with tests/playsaw.cpp.
It works as intended with jack2-dbus on up to date Arch Linux - returns only one supported format: FLOAT32.
It is hard to roll back to state of my application when I noticed this issue.
I'm not using JACK now but I will back to it soon.

It is possible that all my troubles occurred again due to two RtAudio instances in one app - I wrote about it.
I'm going to "merge" them so I will see then.
I'm sorry for a bit mess :-)

[garyscavone]

I'm closing this issue.