[adw888]

Hi all, I've already posted this problem on the Oracle forums in the Java Sound subforum but it doesn't seem very active and I remember getting some great responses the last time I was on here (which appears to be over 4 years ago now!).

I'm using Java Sound to play audio files (in standard PCM format) but I've noticed that it does not correctly play 24 bit data, in that the data output from the soundcard does not match the input from the file. It works fine for 16 bit (and even 8 bit) audio data, but not for 24 bit (and presumably 32 bit, but I have no real 32 bit audio files to test) files. From the output it appears that Java Sound is doing some extra (and unwanted) processing to the audio data before passing it to the soundcard. I can say for certain that it is Java Sound doing this because if I run the same test using ASIO to play the file then there is no problem and the data matches as expected.

A bit more information on the setup:
- Java JRE latest version (7u7 I think), running on Windows XP SP3.
- Sound played using AudioPlayer example on jsresources.org (I firstly tried using my own code, but switched to this in case I had made a mistake, the results are the same on both).
- The audio is played is on an M-Audio soundcard via the digital (S/PDIF) out, which is directly connected (via an external cable) to a digital in on a Lynx soundcard (in the same PC), where it is recorded (using Sony Sound Forge).
- The recorded file is then compared with the input Wave file.

For the test, four different input Wave files are used (generated from the same source file):
- 16 bit, 44.1 kHz
- 16 bit, 48 kHz
- 24 bit, 44.1 kHz
- 24 bit, 48 kHz

Using ASIO to play back the test files, all four of the files produced the correct output (the recorded data matches the input Wave file data byte for byte, after shifting to align the starting positions).

Using Java to play back the test files, the 16 bit ones (both the 44.1 kHz and 48 kHz) produce the correct output, whereas the 24 bit ones (both the 44.1 kHz and 48 kHz) do not. Not only that, but the way in which the output is incorrect is inconsistent (if I run the test two times, it produces a different output each time, neither of which comes close to matching the input file). So not only is Java sound playing the 24 bit files wrongly, it is doing so wrongly in a different way each time. If it will help I can take screenshots of the Java sound output compared to the input file (expected output).

The easiest way to reproduce this would be to use the AudioPlayer example I linked to above, play a 24 bit file and record the output (if you only have one soundcard it might be possible to use its mixer to route the data appropriately to allow it to be captured). While it's not wrong enough that I can hear any difference, it does kind of defeat the purpose of hi-resolution audio if the data is being altered in some unexpected way (you risk losing any gains from using 24 bit over 16 bit, though I don't really want to get into that argument here).

So to phrase this as a question - how can I get Java Sound to play back 24 bit audio correctly?

Thanks in advance for any help,

Alex

This post has been edited by macosxnerd101: 27 September 2012 - 02:05 PM
Reason for edit:: Added [Resolved] to title

[adw888]

I've finally solved this (well kind of) - it works fine in Linux, so it's a Windows Java Sound / Microsoft DirectSound issue.

Details follow (copied from my post on the Oracle Java Sound subforum):
---
The following outlines the testing and results using Java Sound with the same PC and sound card(s) using Linux, Windows XP and Windows 7 (all 64 bit).

The set up is similar to before, with the test player PC connected directly (via S/PDIF out) to a recorder PC (with a Lynx soundcard). The player PC uses a ESI Juli@ soundcard (as it has Linux ALSA support).

With Linux (Fedora 17 to be precise), 16 bit and 24 bit audio plays perfectly using Java Sound with the default ALSA driver for the ESI soundcard. In fact, it even works perfectly using the onboard Realtek sound chip via its (RCA) S/PDIF out.

With Windows XP, the same results are seen as before: 16 bit audio plays perfectly using Java Sound but 24 bit audio is processed in some way.

With Windows 7, it's even worse: 16 bit audio plays (but some kind of processing is done) and 24 bit audio refuses to play at all.

This prompted me to check the supported audio formats for a given device line in Java using:

DataLine.Info dataLineInfo = (DataLine.Info) lineInfo;

and then looping through:

for (AudioFormat lineFormat : dataLineInfo.getFormats())

I didn't do this before as I didn't realise that casting to DataLine.Info exposed more information.

In Windows 7 the supported audio formats are reported as:
---
Format #1: PCM_UNSIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
Format #2: PCM_SIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
Format #3: PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, little-endian
Format #4: PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, big-endian
Format #5: PCM_UNSIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
Format #6: PCM_SIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
Format #7: PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, little-endian
Format #8: PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, big-endian
---
And it's the same list for both the ESI and Realtek devices, so this seems to be due to the Windows Java Sound implementation and/or DirectSound.
It also explains why 24 bit refuses to play, because it is not a supported format.

In Windows XP the supported audio formats are reported as (again the same for both devices):
---
Format #1: PCM_UNSIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
Format #2: PCM_SIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
Format #3: PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, little-endian
Format #4: PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, big-endian
Format #5: PCM_UNSIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
Format #6: PCM_SIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
Format #7: PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, little-endian
Format #8: PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, big-endian
---
So the reported formats are the same as for Windows 7, but the difference is that Java Sound will let you play 24 bit audio data even though it isn't on the list of supported audio formats.
My guess is that Windows Java Sound / DirectSound doesn't actually support 24 bit, but accepts that format and presumably converts down to 16 bit, which the soundcard then processes to 24 bit, hence the incorrect data output.

In Linux (Fedora 17), the supported audio formats are reported as:
---
Format #1: PCM_SIGNED unknown sample rate, 32 bit, mono, 4 bytes/frame, little-endian
Format #2: PCM_SIGNED unknown sample rate, 32 bit, mono, 4 bytes/frame, big-endian
Format #3: PCM_SIGNED unknown sample rate, 32 bit, stereo, 8 bytes/frame, little-endian
Format #4: PCM_SIGNED unknown sample rate, 32 bit, stereo, 8 bytes/frame, big-endian
Format #5: PCM_SIGNED unknown sample rate, 24 bit, mono, 4 bytes/frame, little-endian
Format #6: PCM_SIGNED unknown sample rate, 24 bit, mono, 4 bytes/frame, big-endian
Format #7: PCM_SIGNED unknown sample rate, 24 bit, stereo, 8 bytes/frame, little-endian
Format #8: PCM_SIGNED unknown sample rate, 24 bit, stereo, 8 bytes/frame, big-endian
Format #9: PCM_SIGNED unknown sample rate, 24 bit, mono, 3 bytes/frame, little-endian
Format #10: PCM_SIGNED unknown sample rate, 24 bit, mono, 3 bytes/frame, big-endian
Format #11: PCM_SIGNED unknown sample rate, 24 bit, stereo, 6 bytes/frame, little-endian
Format #12: PCM_SIGNED unknown sample rate, 24 bit, stereo, 6 bytes/frame, big-endian
Format #13: PCM_SIGNED unknown sample rate, 20 bit, mono, 3 bytes/frame, little-endian
Format #14: PCM_SIGNED unknown sample rate, 20 bit, mono, 3 bytes/frame, big-endian
Format #15: PCM_SIGNED unknown sample rate, 20 bit, stereo, 6 bytes/frame, little-endian
Format #16: PCM_SIGNED unknown sample rate, 20 bit, stereo, 6 bytes/frame, big-endian
Format #17: PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, little-endian
Format #18: PCM_SIGNED unknown sample rate, 16 bit, mono, 2 bytes/frame, big-endian
Format #19: PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, little-endian
Format #20: PCM_SIGNED unknown sample rate, 16 bit, stereo, 4 bytes/frame, big-endian
Format #21: PCM_SIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
Format #22: PCM_UNSIGNED unknown sample rate, 8 bit, mono, 1 bytes/frame,
Format #23: PCM_SIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
Format #24: PCM_UNSIGNED unknown sample rate, 8 bit, stereo, 2 bytes/frame,
---
Again with the same list for both devices, but reported in a different order.

So Linux Java Sound / ALSA properly supports 24 bit audio, which explains why it handles it perfectly whereas Windows does not.

Seeing as the supported audio formats appear to be the same regardless of soundcard and that both soundcards work perfectly using Linux, the lack of 24 bit playback seems to be a limitation of DirectSound and/or the Windows Java Sound implementation rather than device drivers or Java Sound more generally.

Hope this is helpful - I'm marking it as answered even though it isn't fully solved (doesn't work in Windows, works fine in Linux).
---

[farrell2k]

Interesting find. Reminds me of the Java timer granularity on windows vs linux, which may be fixed now for windows.

[adw888]

Just a quick message to say it also works on Mac, so it's only Windows where there's a problem.