Date: Mon, 3 May 1999 12:20:15 -0700 (PDT)
From: Liang He <###@###.###>
To: ###@###.###, ###@###.###
Subject: Re: JMF 2.0 Workspace
Cc: ###@###.###, ###@###.###, ###@###.###
MIME-Version: 1.0

Babu and Ivan,

I have implemented G.728 native decoder using byte arrays. I would like to
document the difference between doing it in byte arrays and in short arrays.

Using byte arrays, the native code looks like following.

    short code[NCODEWORDS];
    short data[NDATASAMPLES];
    byte *pcode = (byte *)code;
    byte *pdata = (byte *)data;
    byte *pinbuffer = inBuffer + jInOffset;
    byte *poutbuffer = outBuffer + jOutOffset;

    for (k = 0; k < nframes; k++) {
/* convert input from byte array to short array */
        for (i = 0; i < codeframesize; i ++) {
            pcode[i] = pinbuffer[0];
            pinbuffer ++;
        }
        for (i = 0; i < ncodewords; i ++) {
g728_decode(data + (i * 5), code[i], decoder, postfilter);
        }
/* convert output from short array to byte array */
        for (i = 0; i < dataframesize; i ++) {
            poutbuffer[0] = pdata[i];
            poutbuffer ++;
        }
    }

If we can use short arrays, it would look like following.

    for (k = 0; k < nframes; k++) {
        for (i = 0; i < ncodewords; i ++) {
g728_decode(data + (i * 5), code[i], decoder, postfilter);
        }
    }

Although there will be faster processors in systems and better technology
(such as HotSpot) in JVM, an implementation with the conversions will never
be faster than one without it. The overhead may seem not much. A lot of
small overhead will add up and have am impact in performance.

Since JavaSound has not FCS-ed yet, I strongly suggest that you consider
adding short array support to it.

-Liang

> Please let us know when and what you are going to do for short arrays.
> So we can decide when and how to do our part.
>
> -Liang
>
> > Liang,
> >
> > > > But JavaSound renderer accepts only byte arrays.
> > >
> > > Why? JavaSound is advertised as the solution to 8KHz 8bit sound
> > > (remember the JMF demo on JavaOne'97?). If most of the data
> > > JavaSound plays is 16-bit data, then why does it only accept byte
> > > array? So there is conversion overhead somewhere in JavaSound
> > > render. Why not remove it?
> >
> > This could be better answered by the JavaSound team. But basically,
> > JavaSound accepts only byte array input, mostly for API simplicity
> > and uniformity, I think.
> >
> > > With option 1, we will have conversion overhead in native code,
> > > like IBM GSM codec. This will have an impact on performance.
> >
> > Unfortunately yes. Although for 32 bit video, we do support int
> > array at the video renderers judging that the performance impact on
> > video will be more significant than on the audio side...
> >
> > Ivan