Hi!

The routine that does float -> integer conversion is defined in convert.cc
and looks like this (it's called from Synth_PLAY):

void Arts::convert_stereo_2float_i16le(unsigned long samples, float *left, float 
*right, unsigned char *to)
{
    float *end = left+samples;
    long syn;
 
    while(left < end)
    {
        syn = QRound((*left++)*32767);
 
        if(syn < -32768) syn = -32768;              /* clipping */
        if(syn > 32767) syn = 32767;
 
        *to++ = syn & 0xff;
        *to++ = (syn >> 8) & 0xff;
                [...]

The signal as float is between -1.0 and 1.0 - after the multiplication
and conversion to integer it is between -32767 and 32767. You see that it
is signed there, i.e. 

 0x7fff  (represents 1.0)
 0x7ffe
 ...
 0x0001
 0x0000  (represents 0.0)
 0xffff
 ...
 0x8002
 0x8001  (represents -1.0)

Then, the *to++ lines take the least significant byte first, and then the
most significant byte - no further conversion is done. That means that
a value which is a tad bit larger than -1.0 would be written as

fragment_buffer[i] = 0x02; fragment_buffer[i+1] = 0x80;

This is called little endian because the number 0x1234 would be represented
as 0x34 0x12, that is, the endian gets little - it is confusing, because the
endian still holds the most significant byte.

   Cu... Stefan

On Sat, Dec 02, 2000 at 12:29:07AM +0800, Nikolaus J. Sucher wrote:
> Stefan,
> 
> Ok, after having read through the OSS programmers guide 
>(http://www.opensound.com/pguide/oss.pdf),
> I am now convinced that the problems stem from the big endian nature of the Sparc 
>while you send
> little endian data down to audiosubsystem.  If I understand this right, you add the 
>data from
> wBuffer to the fragment buffer. The type of the fragment buffer is char. Does this 
>mean that you
> split the 16 bit data in two parts that you add to the fragment_buffer (i.e. big 
>byte into
> fragment_buffer[i], small byte into fragment_buffer[i+1])?  What is happening with 
>sign?  Can you
> elaborate on this, please?
> 
> Tx,
> Nikolaus
> 
> 
> "Nikolaus J. Sucher" wrote:
> 
> > Hi Stefan,
> >
> > I did what ;you suggested and compiled the testasubsystem program. Using this 
>program, Ihave
> > ascertained that the audiosubsystem gets data, it reads the data, puts the data 
>into the
> > fragment buffer and writes the data to the sound card. HOWEVER, for some 
>mysterious reason, I
> > don't get the sine wave sound on my audio output but more like a hammering. I 
>checked all the
> > parameters (encoding, sample rate, bits/sample etc), everything appears to be 
>allright. Byte
> > swapping doesn't make any difference either. Do you have any suggestion or idea 
>what might be
> > missing here???
> >
> > Have a great weekend,
> > Nikolaus
> >
> > Stefan Westerfeld wrote:
> >
> > >    Hi!
> > >
> > > On Fri, Dec 01, 2000 at 12:55:26AM +0800, Nikolaus J. Sucher wrote:
> > > > Stefan Westerfeld wrote:
> > > >
> > > > >    Hi!
> > > > >
> > > > > On Thu, Nov 30, 2000 at 11:00:25AM +0800, Nikolaus J. Sucher wrote:
> > > > > > > 2. reimplement handleIO(), call needMore() exactly once
> > > > > >
> > > > > > OK!
> > > > > >
> > > > > > > and write through
> > > > > > >    the result to the audio device (the encoding aRts produces is signed,
> > > > > > >    16bit, little endian)
> > > > > >
> > > > > > I am very close. One more question:  what is the name of the buffer where 
>the data goes
> > > > > > that comes from the producer (producer->needMore();).  How do I "write 
>through"?  I am
> > > > > > not sufe yet if I have to convert from little endian to bigendian or not. 
>I will check
> > > > > > on that.
> > > > >
> > > > > producer->needMore will lead to a call of AudioSubSystem::write - the OSS
> > > > > implementation puts the data in wBuffer, and later (in handleIO) gets it
> > > > > from there and writes it to the audio device.
> > > > >
> > > > > So you can either keep that mechanism, then you can write what is in
> > > > > wBuffer after calling needMore, or reimplement AudioSubSystem::write to
> > > > > "write through" directly.
> > > >
> > > > Sorry, that I keep bothering about this but I am still learning...
> > > > I am stuck here.  I don't know how to actually read what is in the wBuffer. I 
>only get
> > > > click, click, click from my audio, no matter  what I try.  When I check the OSS
> > > > implementation, it appears as if I never get anything into the fragment_buffer 
>except
> > > > zeroes????
> > > > I very much appreciate your help and patience!!
> > >
> > > What might be helpful is if you don't try to get artsd working at first, but
> > > testasubsys (which is in kdelibs/arts/examples - you need to do make check
> > > to get it compiled). It plays a 2 seconds sine wave. That should be suitable
> > > for testing.
> > >
> > > With artsd, the normal thing you should expect when you start it is getting
> > > zeros, and only if you use applications, like artsplay, kaiman, artsbuilder
> > > or similar, you'll get some sound.
> > >
> > >    Cu... Stefan
> > > --
> > >   -* Stefan Westerfeld, [EMAIL PROTECTED] (PGP!), Hamburg/Germany
> > >      KDE Developer, project infos at http://space.twc.de/~stefan/kde *-

Content-Description: Card for Nikolaus J. Sucher


-- 
  -* Stefan Westerfeld, [EMAIL PROTECTED] (PGP!), Hamburg/Germany
     KDE Developer, project infos at http://space.twc.de/~stefan/kde *-         

Reply via email to