Subsonic / Bugs / #116 Jukebox mode does not play 6 channel FLAC

Ok, so I fixed this problem for my system. It was fairly complicated as I don't have any experience with audio file formats and their conversion, and I fear that my fix is only applicable to my setup. The later is also the reason why I think this ticket should stay open until the problem is really addressed. Nevertheless, some components of it could be integrated into Subsonic as long as someone with knowledge about audio formats reviews them first.

The actual fix consists of 4 parts.

(1) System buffer size (ALSA)
It seems that my system did not set the sound card buffer size large enough to handle all audio formats that the card supports.
Trying to play multi-channel files with Subsonic always failed with the exception <core>javax.sound.sampled.LineUnavailableException</core>
The same file with mplayer also yields this warning:

% mplayer -ao alsa:device=hw=0.8 -channels 6 sample.flac
[AO_ALSA] Unable to set buffer time near: Invalid argument
Failed to initialize audio driver 'alsa:device=hw=0.8'

Did some research, found http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/072265.html
And sure enough, the buffer size was small:

% cat /proc/asound/card0/pcm8p/sub0/prealloc 
64

Changing the buffer size to something higher makes the problem go away.

% echo 1024 > /proc/asound/card0/pcm8p/sub0/prealloc

(2) java.lang.IllegalArgumentException: illegal request to write non-integral number of frames
The exception is thrown in net.sourceforge.subsonic.service.jukebox.AudioPlayer during line.write(buffer, 0, n) in line 184.

The Javadoc for javax.sound.sampled.SourceDataLine states that

The number of bytes to write must represent an integral number of sample frames, such that: [ bytes written ] % [frame size in bytes ] == 0

This is no problem as long as the frame size is some power of 2. But for 6 channel audio files, the frame size is 12 (2 bytes per sample), which could lead to buffer not fulfilling the specification.
I fixed this by adding the parameters int bytesPerFrame to AudioDataWriter and changing the PLAYING case of run() to

case PLAYING:
    int n = in.read(buffer);

    if (n == -1) {
        setState(State.EOM);
        return;
    }

    // "integral number of bytes"
    // [ bytes written ] % [frame size in bytes ] == 0
    // This loop will fill the buffer from the stream s.t.
    // the spec holds.
    while (n % bytesPerFrame != 0) {
        int j = in.read(buffer, n, bytesPerFrame
                - (n % bytesPerFrame));
        if (j == -1) {
            setState(State.EOM);
            n = n - (n % bytesPerFrame);
        } else {
            n = n + j;
        }
    }
    line.write(buffer, 0, n);
    break;

(3) Hardware support
After (1) and (2), Subsonic finally started playing multi-channel files. But after listening in, I noticed that the channels were in the wrong order. Also, one channel was always missing and instead, a typical, high-pitched "pfft" sound was audible. Strange enough, mplayer played the file correctly. But looking closer at the mplayer output, I noticed that it converted the file from s32be to s32le.

I checked Java's understanding of the capabilities of my sound card (its a Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)) and found that it thought it would support big endian encoding of PCM streams. mplayer differed there and it played the file just fine, so I assumed that Java does not report the right hardware capabilities.

I tried to produce multi-channel files for Java that were (a) in s32le or s16le and (b) readable, but I failed. I got Java only to accept multi-channel sound streams in .au format (as produced by ffmpeg -f au). Neither wav nor aiff did work. As .au is strictly big endian encoded, I had to change the encoding in Java itself.

I did this by changing the constructor of AudioPlayer to the following:

public AudioPlayer(InputStream in, Listener listener) throws Exception {
    this.in = new BufferedInputStream(in);
    this.listener = listener;

    AudioFormat format = AudioSystem.getAudioFileFormat(this.in).getFormat();

    // try reencoding in PCM Signed little endian with same sample rate 
    // and size as input
    AudioFormat target = new AudioFormat(Encoding.PCM_SIGNED, 
        format.getSampleRate(), format.getSampleSizeInBits(),
        format.getChannels(), format.getFrameSize(),
        format.getFrameRate(), false);

    if (AudioSystem.isConversionSupported(target, format)) {
        AudioInputStream stream = AudioSystem.getAudioInputStream(target,
                AudioSystem.getAudioInputStream(this.in));
        in = stream;
        line = AudioSystem.getSourceDataLine(target);
    } else {
        // if this fails, just use the old method 
        line = AudioSystem.getSourceDataLine(format);
    }

    line.open(format);

    if (line.isControlSupported(FloatControl.Type.MASTER_GAIN)) {
        gainControl = (FloatControl) line.getControl(FloatControl.Type.MASTER_GAIN);
        setGain(DEFAULT_GAIN);
    }
    new AudioDataWriter(format.getFrameSize(), format.getChannels(), order);
}

Sure enough, now all channels were present. But they were still in the wrong order.

(4) Channel ordering
As mplayer did play all the audio files on the right channels, I again assumed that Java did not map the sound hardware properly.

After experimenting with the 8 channel sound test file from the Gentoo wiki ("Microsoft's 8 Channel Speaker Test"), I tried to remap the channels in Subsonic itself. Unfortunately, Java does not have any kind of support (or at least I could not find it), to show the target mapping or assist in the remapping. I therefore coded some primitive reordering function to reorder the bytes directly in the input stream:

private static void reorderBufferContent(byte[] buffer, int offset,
            int length, int channelSize, int channelCount, int[] order) {
    int frameSize = channelSize * channelCount;
    byte[] tmp = new byte[frameSize];

    for (int i = offset; i < offset + length; i = i + frameSize) {
        // iterate over the buffer frame-wise (starting at offset)
        // buffer[i] ... buffer[i+framesize] is one frame
        for (int j = 0; j < channelCount; j++) {
            // iterate over each channel
            // j is position in original, order[j] is target
            for (int k = 0; k < channelSize; k++) {
                // iterate over the individual bytes of the current channel
                // j of the buffer
                tmp[order[j] * channelSize + k] = buffer[i + j
                        * channelSize + k];
            }
        }
        // write back
        for (int j = 0; j < frameSize; j++) {
            buffer[i + j] = tmp[j];
        }
    }
}

The function assumes that a frame consists of successive channels with size channelSize in bytes and ordered from 0 to channelCount - 1. It uses the parameter order to map from the source position of a channel to a target position. My setup consists of the following 6 output channels:

0 front-left
1 front right
2 back left (6)
3 back right (7)
4 center
5 lfe

As I tested an 8 channel file, side left and right were correctly mapped to back left and right, respectively. After some testing, I found that order = {0, 1, 4, 5, 2, 3, 6, 7} does the trick and brinsg my channels in the right order.

Conclusion
My problem is solved - for now. I think part 1 and 2 of my solution could help other people as-is. But part 3 and 4 seem to be too specific to my setup and may also dependent on the Java VM (I use dev-java/icedtea-bin-7.2.4.3).
The problem in Subsonic as a whole remains.

PS: I am the original reporter of this ticket (I just forgot to login after I pressed submit, so, apologies).
PPS: I attached a diff to the current trunk version for reference.

subsonic-audioplayer-diff

Jukebox mode does not play 6 channel FLAC

Group

Searches

Help

#116 Jukebox mode does not play 6 channel FLAC

Discussion