Bug in OSS simulation (ALSA 0.9.4)

Bug in OSS simulation (ALSA 0.9.4)

[Carlo Wood]

I pinpointed the problem and wrote a small program
to illustrate the problem.

When compiling the program given below with:

  gcc -DUSE_DSP_SETFMT=0 troep.c

it runs fine.

But, when compiling it with:

  gcc -DUSE_DSP_SETFMT=1 troep.c

It stops rather quickly with reading data.

Example output of the latter:

~>a.out
Fragment size: 1024
Number of fragments: 32767
Number of channels: 1
Sample rate: 22050
Read 1024 bytes.
Number of full fragments that can be read or written without blocking: 0
Total number of fragments allocated for buffering: 2
Size of a fragment in bytes: 1024
Number of bytes that can be read or written immediately without blocking: 0
#fragments, #bytes: 0, 0
#fragments, #bytes: 1, 1632
Read 1024 bytes.
#fragments, #bytes: 2, 2048
Read 1024 bytes.
#fragments, #bytes: 1, 1024
Read 1024 bytes.
#fragments, #bytes: 0, 0
#fragments, #bytes: 0, 0
#fragments, #bytes: 0, 0
...etc

-- 
Carlo Wood <carlo@alinoe.com>


The program:


#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <sys/ioctl.h>
#include <unistd.h>
#include <linux/soundcard.h>
#include <time.h>

int main(void)
{
  int res;
  char buf[1024];

  int fd = open("/dev/dsp", O_RDONLY);
  if (fd == -1)
  {
    perror("open");
    exit(1);
  }

  res = 0x7fff000a;
  if (ioctl(fd, SNDCTL_DSP_SETFRAGMENT, &res) == -1)
  {
    perror("ioctl");
    exit(1);
  }
  printf("Fragment size: %d\n", 1 << (res & 0xffff));
  printf("Number of fragments: %d\n", res >> 16);

#if USE_DSP_SETFMT
  res = AFMT_S16_LE;
  if (ioctl(fd, SNDCTL_DSP_SETFMT, &res) == -1)
  {
    perror("ioctl");
    exit(1);
  }
#endif

  res = 0;	// Not stereo (1 channel).
  if (ioctl(fd, SNDCTL_DSP_STEREO, &res) == -1)
  {
    perror("ioctl");
    exit(1);
  }
  printf("Number of channels: %d\n", res ? 2 : 1);

  res = 22050;
  if (ioctl(fd, SOUND_PCM_READ_RATE, 0xbfffdcfc) == -1)
  {
    perror("ioctl");
    exit(1);
  }
  printf("Sample rate: %d\n", res);

  ssize_t rlen = read(fd, buf, sizeof(buf));
  if (rlen <= 0)
  {
    perror("read");
    exit(1);
  }
  printf("Read %d bytes.\n", rlen);

  audio_buf_info info;

  if (ioctl(fd, SNDCTL_DSP_GETISPACE, &info) == -1)
  {
    perror("read");
    exit(1);
  }
  printf("Number of full fragments that can be read or written without blocking: %d\n", info.fragments);
  printf("Total number of fragments allocated for buffering: %d\n", info.fragstotal);
  printf("Size of a fragment in bytes: %d\n", info.fragsize);
  printf("Number of bytes that can be read or written immediately without blocking: %d\n", info.bytes);

  int i;
  for (i = 0; i < 100; ++i)
  {
    if (ioctl(fd, SNDCTL_DSP_GETISPACE, &info) == -1)
    {
      perror("read");
      exit(1);
    }
    printf("#fragments, #bytes: %d, %d\n", info.fragments, info.bytes);
    if (info.fragments > 0)
    {
      ssize_t rlen = read(fd, buf, sizeof(buf));
      if (rlen <= 0)
      {
	perror("read");
	exit(1);
      }
      printf("Read %d bytes.\n", rlen);
    }
    static struct timespec naptime = { 0, 100000000 };
    nanosleep(&naptime, 0);
  }

  close(fd);
  return 0;
}


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps

Re: Bug in OSS simulation (ALSA 0.9.4)

[Carlo Wood]

On Thu, Jul 10, 2003 at 03:33:26AM +0200, Carlo Wood wrote:
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 1, 1632
> Read 1024 bytes.
> #fragments, #bytes: 2, 2048
> Read 1024 bytes.
> #fragments, #bytes: 1, 1024
> Read 1024 bytes.
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 0, 0
> ...etc


Ah... I noticed something else.
It doesn't have to do with whether or not
using SNDCTL_DSP_SETFMT, but with having
an overrun of the number of buffers.

Why is the number of allocated buffers
so low?!

And, is it normal that when the buffers
did overrun that nothing is returned anymore?
How about just skipping it? :/

The problem of ViaVoice is probably that
after it opened /dev/dsp, it first does
something that eats cpu for half a second.
With only 2 buffers of 1024 bytes, I immedeately
get an overrun.

-- 
Carlo Wood <carlo@alinoe.com>


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps

Re: Bug in OSS simulation (ALSA 0.9.4)

[James Courtier-Dutton]

Carlo Wood wrote:
> I pinpointed the problem and wrote a small program
> to illustrate the problem.
> 
> When compiling the program given below with:
> 
>   gcc -DUSE_DSP_SETFMT=0 troep.c
> 
> it runs fine.
> 
> But, when compiling it with:
> 
>   gcc -DUSE_DSP_SETFMT=1 troep.c
> 
> It stops rather quickly with reading data.
> 
> Example output of the latter:
> 
> ~>a.out
> Fragment size: 1024
> Number of fragments: 32767
> Number of channels: 1
> Sample rate: 22050
> Read 1024 bytes.
> Number of full fragments that can be read or written without blocking: 0
> Total number of fragments allocated for buffering: 2
> Size of a fragment in bytes: 1024
> Number of bytes that can be read or written immediately without blocking: 0
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 1, 1632
> Read 1024 bytes.
> #fragments, #bytes: 2, 2048
> Read 1024 bytes.
> #fragments, #bytes: 1, 1024
> Read 1024 bytes.
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 0, 0
> ...etc
> 
Why don't you just use /proc/asound to gather all the info you need, 
like buffer and period sizes.
E.g.
While playing a sound file: -
cat /proc/asound/oss/sndstat
cat /proc/asound/card0/pcm0p/info

cat /proc/asound/card0/pcm0p/sub0/hw_params
cat /proc/asound/card0/pcm0p/sub0/info
cat /proc/asound/card0/pcm0p/sub0/status
cat /proc/asound/card0/pcm0p/sub0/sw_params

If recording a sound, use pcm0c instead of pcm0p

Cheers
James



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps

Re: Bug in OSS simulation (ALSA 0.9.4)

[Carlo Wood]

On Thu, Jul 10, 2003 at 02:15:25PM +0100, James Courtier-Dutton wrote:
> Why don't you just use /proc/asound to gather all the info you need, 
> like buffer and period sizes.
> E.g.
> While playing a sound file: -
> cat /proc/asound/oss/sndstat
> cat /proc/asound/card0/pcm0p/info
> 
> cat /proc/asound/card0/pcm0p/sub0/hw_params
> cat /proc/asound/card0/pcm0p/sub0/info
> cat /proc/asound/card0/pcm0p/sub0/status
> cat /proc/asound/card0/pcm0p/sub0/sw_params
> 
> If recording a sound, use pcm0c instead of pcm0p

I am recording.  This is the result:

>cat /proc/asound/oss/sndstat
Sound Driver:3.8.1a-980706 (ALSA v0.9.4 emulation code)
Kernel: Linux ansset 2.5.74-debug #3 Wed Jul 9 14:16:52 CEST 2003 i686
Config options: 0

Installed drivers:
Type 10: ALSA emulation

Card config:
Sound Blaster Live! (rev.8) at 0xa400, irq 9

Audio devices:
0: EMU10K1 (DUPLEX)

Synth devices: NOT ENABLED IN CONFIG

Midi devices:
0: EMU10K1 MPU-401 (UART)

Timers:
7: system timer

Mixers:
0: TriTech TR28602

>cat /proc/asound/card0/pcm0c/info
card: 0
device: 0
subdevice: 0
stream: CAPTURE
id: emu10k1
name: EMU10K1
subname: subdevice #0
class: 0
subclass: 0
subdevices_count: 1
subdevices_avail: 0

>cat /proc/asound/card0/pcm0c/sub0/hw_params
access: RW_INTERLEAVED
format: S16_LE
subformat: STD
channels: 1
rate: 22050 (22050/1)
period_size: 512
buffer_size: 1024
tick_time: 1000
OSS format: S16_LE
OSS channels: 1
OSS rate: 22050
OSS period bytes: 1024
OSS periods: 2

>cat /proc/asound/card0/pcm0c/sub0/status
state: XRUN
trigger_time: 1057875818.000705646
tstamp      : 1057875855.000974402
delay       : 0
avail       : 1024
avail_max   : 0
-----
hw_ptr      : 1536
appl_ptr    : 512

>cat /proc/asound/card0/pcm0c/sub0/sw_params
tstamp_mode: NONE
period_step: 1
sleep_min: 0
avail_min: 512
xfer_align: 1
start_threshold: 1
stop_threshold: 1024
silence_threshold: 0
silence_size: 0
boundary: 1073741824



At this moment the application (of which I have no source code
thus) is calling

  audio_buf_info info;
  ioctl(fd, SNDCTL_DSP_GETISPACE, &info);

in a loop and get returned in 'info'
that there is no data to be read (info.bytes == 0).

This seems to be caused by the fact that more than 2048
bytes of data were available before the application started
to actually read data; and because there is only a buffer
of 2048 bytes:

OSS period bytes: 1024
OSS periods: 2

Increasing the number of 'periods' would be nice.
But I have no idea why I only GET 2 period - the request is
for 'as much as possible' (0x7fff).
See the call
    res = 0x7fff000a;
    if (ioctl(fd, SNDCTL_DSP_SETFRAGMENT, &res) == -1)
in my test program.

Changing that value to say '0x4000a' also just gives 2 'periods'
instead of the requested 4.

Can you please analyse the data of /proc/asound above
and give a new hint of what to do next?

-- 
Carlo Wood <carlo@alinoe.com>


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Kai Vehmanen]

On Thu, 10 Jul 2003, Carlo Wood wrote:

> But, when compiling it with:
>   gcc -DUSE_DSP_SETFMT=1 troep.c
> It stops rather quickly with reading data.

Hmm, I tested on my machine and this seems to work fine (ALSA 0.9.3c 
/ 2.4.19 / SB128 (snd-ens1371 module).

> ~>a.out
> Fragment size: 1024
> Number of fragments: 32767
> Number of channels: 1
> Sample rate: 22050
> Read 1024 bytes.
> Number of full fragments that can be read or written without blocking: 0
> Total number of fragments allocated for buffering: 2
> Size of a fragment in bytes: 1024
> Number of bytes that can be read or written immediately without blocking: 0
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 1, 1632
> Read 1024 bytes.
> #fragments, #bytes: 2, 2048
> Read 1024 bytes.
> #fragments, #bytes: 1, 1024
> Read 1024 bytes.
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 0, 0

I get:
--cut--
Fragment size: 1024
Number of fragments: 32767
Number of channels: 1
Sample rate: 22050
Read 1024 bytes.
Number of full fragments that can be read or written without blocking: 0
Total number of fragments allocated for buffering: 64
Size of a fragment in bytes: 1024
Number of bytes that can be read or written immediately without blocking: 
0
#fragments, #bytes: 0, 0
#fragments, #bytes: 1, 1696
Read 1024 bytes.
#fragments, #bytes: 2, 2432
Read 1024 bytes.
#fragments, #bytes: 3, 3168
Read 1024 bytes.
#fragments, #bytes: 3, 3904
Read 1024 bytes.
#fragments, #bytes: 4, 4640
Read 1024 bytes.
#fragments, #bytes: 5, 5376
Read 1024 bytes.
#fragments, #bytes: 5, 6112
Read 1024 bytes.
#fragments, #bytes: 6, 6848
Read 1024 bytes.
#fragments, #bytes: 7, 7584
Read 1024 bytes.
#fragments, #bytes: 8, 8320
Read 1024 bytes.
#fragments, #bytes: 8, 9056
Read 1024 bytes.
#fragments, #bytes: 9, 9792
Read 1024 bytes.
#fragments, #bytes: 10, 10528
Read 1024 bytes.
#fragments, #bytes: 11, 11264
Read 1024 bytes.
#fragments, #bytes: 11, 12000
Read 1024 bytes.
#fragments, #bytes: 12, 12736
Read 1024 bytes.
#fragments, #bytes: 13, 13472
Read 1024 bytes.
...
--cut--

More in the next post...

-- 
 http://www.eca.cx
 Audio software for Linux!




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Kai Vehmanen]

On Thu, 10 Jul 2003, Carlo Wood wrote:

>> #fragments, #bytes: 0, 0
>> #fragments, #bytes: 1, 1632
>> Read 1024 bytes.
>> #fragments, #bytes: 2, 2048
[...]
> Ah... I noticed something else.
> It doesn't have to do with whether or not
> using SNDCTL_DSP_SETFMT, but with having
> an overrun of the number of buffers.
[...]
> Why is the number of allocated buffers
> so low?!

This is a feature of the SB-Live driver: in capture/recording direction,
it supports max two interrupts per buffer. To increase the total
buffersize you need to increase fragment size. In playback mode up to 1024 
interrupts per buffer is supported. I got this info by reading through the 
driver code, so I don't have further info about the issue.

> And, is it normal that when the buffers
> did overrun that nothing is returned anymore?
> How about just skipping it? :/

No, this definitely looks like a driver bug. In OSS-emulation mode the 
xruns should be ignored (just lke kernel/OSS drivers do).

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[James Courtier-Dutton]

Kai Vehmanen wrote:
> On Thu, 10 Jul 2003, Carlo Wood wrote:
> 
> 
>>But, when compiling it with:
>>  gcc -DUSE_DSP_SETFMT=1 troep.c
>>It stops rather quickly with reading data.
> 
> 
My SB Live has the same problems as Carlo's

Cheers
James




-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Kai Vehmanen]

On Thu, 10 Jul 2003, Carlo Wood wrote:

> ~>a.out
> Fragment size: 1024
> Number of fragments: 32767
> Number of channels: 1
> Sample rate: 22050
> Read 1024 bytes.
> Number of full fragments that can be read or written without blocking: 0
> Total number of fragments allocated for buffering: 2
> Size of a fragment in bytes: 1024
> Number of bytes that can be read or written immediately without blocking: 0
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 1, 1632
> Read 1024 bytes.
> #fragments, #bytes: 2, 2048
> Read 1024 bytes.
> #fragments, #bytes: 1, 1024
> Read 1024 bytes.
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 0, 0
> #fragments, #bytes: 0, 0

How about if you make the following change to the test:

--cut--
    printf("#fragments, #bytes: %d, %d\n", info.fragments, info.bytes);
-    if (info.fragments > 0)
-    {
      ssize_t rlen = read(fd, buf, sizeof(buf));
      if (rlen <= 0)
      {
	perror("read");
	exit(1);
      }
      printf("Read %d bytes.\n", rlen);
-    }
    static struct timespec naptime = { 0, 100000000 };
--cut--

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Carlo Wood]

On Fri, Jul 11, 2003 at 01:54:51AM +0300, Kai Vehmanen wrote:
> No, this definitely looks like a driver bug. In OSS-emulation mode the 
> xruns should be ignored (just lke kernel/OSS drivers do).

Ok.  Any chance that this can be fixed soon?
If only in CVS.

If you have no time to look into it, then
can you at least tell me if it is possible
to run the alsa modules in usermode somehow,
so I can debug them with gdb?

I am afraid I have no experience with kernel
(model) debugging.  Can you give me a pointer
to where I read up on debugging this?

-- 
Carlo Wood <carlo@alinoe.com>


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Carlo Wood]

On Fri, Jul 11, 2003 at 01:49:49AM +0300, Kai Vehmanen wrote:
> Hmm, I tested on my machine and this seems to work fine (ALSA 0.9.3c 
> / 2.4.19 / SB128 (snd-ens1371 module).
> 
> Total number of fragments allocated for buffering: 64

Well, you have 64 fragments - I only 2.

> #fragments, #bytes: 13, 13472
> Read 1024 bytes.

You didn't really test it when you stop here.
13472 < 64 * 1024.

You need to wait till you get an overrun (xrun?).

-- 
Carlo Wood <carlo@alinoe.com>


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Kai Vehmanen]

On Fri, 11 Jul 2003, Carlo Wood wrote:

> On Fri, Jul 11, 2003 at 01:54:51AM +0300, Kai Vehmanen wrote:
>> No, this definitely looks like a driver bug. In OSS-emulation mode the 
>> xruns should be ignored (just lke kernel/OSS drivers do). 
> Ok.  Any chance that this can be fixed soon?
> If only in CVS.

I'm not the right person to answer this unfortunately. You probably 
have to wait for Jaroslav Kysela's and Takashi Iwai's comments. They
are the primary (active :)) ALSA developers and have written the 
the OSS layer.

> If you have no time to look into it, then
> can you at least tell me if it is possible
> to run the alsa modules in usermode somehow,
> so I can debug them with gdb?

One thing to try is the alsa-oss package. This is an alternative
(user-space) implementation of the OSS emulation layer. It relies on the
LD_PRELOAD mechanism. You can test it with:

LD_PRELOAD=/path/to/libaoss.so.0.0.0 ./a.out

... where "a.out" is your test program. You should be able to run ViaVoice
also this way. You can get the alsa-oss package from ALSA CVS or from:
LD_PRELOAD=~/src/alsa-cvs/alsa-oss/.libs/libaoss.so.0.0.0 ./a.out

> I am afraid I have no experience with kernel
> (model) debugging.  Can you give me a pointer
> to where I read up on debugging this?

Adding printk()'s to the alsa-driver code, recompiling and reloading the 
modules is the best (well, IMHO) way to start. The ALSA kernel-space OSS 
emulation code is in 'alsa-driver/acore/oss/*'.

--
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Kai Vehmanen]

On Fri, 11 Jul 2003, Carlo Wood wrote:

>> Total number of fragments allocated for buffering: 64
> Well, you have 64 fragments - I only 2.

Yup, that's because I'm using the snd-ens1371 driver (maximum interrupt 
frequency ~= period size, is driver/card dependent).

>> #fragments, #bytes: 13, 13472
>> Read 1024 bytes.
> You didn't really test it when you stop here.
> 13472 < 64 * 1024.

I increased the size of the loop and eventually managed to reproduce the
same behaviour you are seeing. It happens somewhere around 100-200th
iteration. Hmm, looks strange. I manage to workaround this by change the
test code to:

--cut--
      printf("Read %d bytes.\n", rlen);
      }
    else {
      static struct timespec naptime = { 0, 100000000 };
      nanosleep(&naptime, 0);
    }
--cut--

... hmm, anyways, it's 3:30am already here, so I'll have to call it a day
now.  Good luck in bug hunting, hopefully you can find out the cause.

> You need to wait till you get an overrun (xrun?).

Yups, xruns is a common (ALSA) term for underruns and overruns.

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Carlo Wood]

On Fri, Jul 11, 2003 at 02:09:57AM +0300, Kai Vehmanen wrote:
> How about if you make the following change to the test:
> 
> --cut--
>     printf("#fragments, #bytes: %d, %d\n", info.fragments, info.bytes);
> -    if (info.fragments > 0)
> -    {
>       ssize_t rlen = read(fd, buf, sizeof(buf));
>       if (rlen <= 0)
>       {
> 	perror("read");
> 	exit(1);
>       }
>       printf("Read %d bytes.\n", rlen);
> -    }
>     static struct timespec naptime = { 0, 100000000 };

That gives rather strange output:

Fragment size: 1024
Number of fragments: 32767
Number of channels: 1
Sample rate: 22050
Number of full fragments that can be read or written without blocking: 0
Total number of fragments allocated for buffering: 2
Size of a fragment in bytes: 1024
Number of bytes that can be read or written immediately without blocking: 0
#fragments, #bytes: 0, 0
Read 1024 bytes.  Average bytes/second read: 9579.135446
#fragments, #bytes: 2, 2048
Read 1024 bytes.  Average bytes/second read: 9833.483781
#fragments, #bytes: 1, 1024
Read 1024 bytes.  Average bytes/second read: 9906.130386
#fragments, #bytes: 0, 0
Read 1024 bytes.  Average bytes/second read: 8601.771175
#fragments, #bytes: 1, 1600
Read 1024 bytes.  Average bytes/second read: 8857.074156
#fragments, #bytes: 2, 2048
Read 1024 bytes.  Average bytes/second read: 9034.443817
#fragments, #bytes: 1, 1024
Read 1024 bytes.  Average bytes/second read: 9165.830174
#fragments, #bytes: 0, 0
Read 1024 bytes.  Average bytes/second read: 8631.080318
#fragments, #bytes: 1, 1632
Read 1024 bytes.  Average bytes/second read: 8768.366140
#fragments, #bytes: 2, 2048
Read 1024 bytes.  Average bytes/second read: 8881.310479
#fragments, #bytes: 1, 1024
Read 1024 bytes.  Average bytes/second read: 8975.563423
#fragments, #bytes: 0, 0
Read 1024 bytes.  Average bytes/second read: 8647.230571
#fragments, #bytes: 1, 1600
Read 1024 bytes.  Average bytes/second read: 8741.039482
#fragments, #bytes: 2, 2048
Read 1024 bytes.  Average bytes/second read: 8822.479599
#fragments, #bytes: 1, 1024
Read 1024 bytes.  Average bytes/second read: 8894.586984
#fragments, #bytes: 0, 0
Read 1024 bytes.  Average bytes/second read: 8655.099768
#fragments, #bytes: 1, 1600
Read 1024 bytes.  Average bytes/second read: 8726.444415
#fragments, #bytes: 2, 2048
Read 1024 bytes.  Average bytes/second read: 8790.244507
#fragments, #bytes: 1, 1024
Read 1024 bytes.  Average bytes/second read: 8848.177087
#fragments, #bytes: 0, 0
Read 1024 bytes.  Average bytes/second read: 8660.003933
#fragments, #bytes: 1, 1600
Read 1024 bytes.  Average bytes/second read: 8717.387832
[...cut...]

It doesn't feel right to read bytes when it says
that there are no fragments/bytes available.

Is the average bytes/second correct though?

with

Number of channels: 1
Sample rate: 22050

and AFMT_S16_LE, what should it be?  I am not so good
at calculating things without knowing the unity of the
'rate' ;)... bits/s?  Byte/s?  (16-bit)Words/sec?

Anyway, it seems too low or too high.
When I add back the "if (info.fragments > 0)" test
and decrease the naptime drastically, I get:

#fragments, #bytes: 1, 1088
Read 1024 bytes.  Average bytes/second read: 16057.031185
#fragments, #bytes: 0, 256
#fragments, #bytes: 0, 448
#fragments, #bytes: 0, 640
#fragments, #bytes: 0, 832
#fragments, #bytes: 1, 1024
Read 1024 bytes.  Average bytes/second read: 16060.372190
#fragments, #bytes: 0, 192
#fragments, #bytes: 0, 384
#fragments, #bytes: 0, 608
#fragments, #bytes: 0, 800
#fragments, #bytes: 1, 1024
Read 1024 bytes.  Average bytes/second read: 16059.965127
#fragments, #bytes: 0, 192
#fragments, #bytes: 0, 416
#fragments, #bytes: 0, 608
#fragments, #bytes: 0, 832
#fragments, #bytes: 1, 1024
Read 1024 bytes.  Average bytes/second read: 16059.006144
etc

Still nothing like 22050 - and certainly unequal to 8700.

-- 
Carlo Wood <carlo@alinoe.com>


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Kai Vehmanen]

One more post - I'll promise this is the last one. :)

On Fri, 11 Jul 2003, Carlo Wood wrote:

> That gives rather strange output:

But it's not stopping...? That's at least different behaviour...

> It doesn't feel right to read bytes when it says
> that there are no fragments/bytes available.

That's true, but as the read() is blocking it will wait 
until there is data available before returning.

> Is the average bytes/second correct though?
[...]
> Number of channels: 1
> Sample rate: 22050
> and AFMT_S16_LE, what should it be?  I am not so good
> at calculating things without knowing the unity of the
> 'rate' ;)... bits/s?  Byte/s?  (16-bit)Words/sec?

Hmm, not quite - you are reading 16bit samples at a rate of 22050 per sec, 
so the data rate should be 22050*16/8=44100 bytes per second.

But the rate actually is 8000 (you can check this by catting
/proc/asound/card0/pcm0c/sub0/hw_params). In your  code:

res = 22050;
if (ioctl(fd, SOUND_PCM_READ_RATE, 0xbfffdcfc) == -1)
{
   perror("ioctl");
   exit(1);
}
printf("Sample rate: %d\n", res);

... 'res' is always 22050 no matter what the device reports.
So with 8000, the date rate should be 16000 bytes/sec.

> Anyway, it seems too low or too high.
> When I add back the "if (info.fragments > 0)" test
> and decrease the naptime drastically, I get:

Try my other change to the test code - i.e. only sleep for
naptime when info.fragments is zero.

-- 
 http://www.eca.cx
 Audio software for Linux!



-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Carlo Wood]

On Fri, Jul 11, 2003 at 03:05:28AM +0300, Kai Vehmanen wrote:
> One thing to try is the alsa-oss package. This is an alternative
> (user-space) implementation of the OSS emulation layer. It relies on the
> LD_PRELOAD mechanism. You can test it with:
> 
> LD_PRELOAD=/path/to/libaoss.so.0.0.0 ./a.out
> 
> ... where "a.out" is your test program. You should be able to run ViaVoice
> also this way. You can get the alsa-oss package from ALSA CVS or from:
> LD_PRELOAD=~/src/alsa-cvs/alsa-oss/.libs/libaoss.so.0.0.0 ./a.out

Thanks, this is very useful.

I downloaded the source of ALSA from CVS.
It turns out that I cannot compile it: I have kernel 2.5.74
and the alsa source (alsa-drivers and alsa-kernel) is full
of 'spin_lock_*' function calls that do not exist in kernel 2.5.

Nevertheless, I could compile the alsa-oss library.

This turns out not to be blocking anymore - but, the result of
a SNDCTL_DSP_GETISPACE is unfortunately nonsense :(

I now get:

~>LD_PRELOAD=/usr/src/alsa/alsa-oss/.libs/libaoss.so.0.0.0 a.out
Fragment size: 1024
Number of fragments: 32767
Number of channels: 1
Sample rate: 22050
Number of full fragments that can be read or written without blocking: 0
Total number of fragments allocated for buffering: 2
Size of a fragment in bytes: 2048
Number of bytes that can be read or written immediately without blocking: 1024
Number of full fragments that can be read or written without blocking: 0
Total number of fragments allocated for buffering: 2
Size of a fragment in bytes: 2048
Number of bytes that can be read or written immediately without blocking: 1024
Number of full fragments that can be read or written without blocking: 0
Total number of fragments allocated for buffering: 2
Size of a fragment in bytes: 2048
Number of bytes that can be read or written immediately without blocking: 1024
Number of full fragments that can be read or written without blocking: 0
Total number of fragments allocated for buffering: 2
Size of a fragment in bytes: 2048
Number of bytes that can be read or written immediately without blocking: 1024
Number of full fragments that can be read or written without blocking: 1
Total number of fragments allocated for buffering: 2
Size of a fragment in bytes: 2048
Number of bytes that can be read or written immediately without blocking: 3072
Read 1024 bytes.
etc

The size of a fragment is NOT 2048... it is 1024.
It also reports 3072 bytes available, which is more than the total size of the buffer!

I am not sure what the application will do with mis-information like this.

-- 
Carlo Wood <carlo@alinoe.com>


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1

Re: Bug in OSS simulation (ALSA 0.9.4)

[Carlo Wood]

On Fri, Jul 11, 2003 at 03:44:34AM +0300, Kai Vehmanen wrote:
> Hmm, not quite - you are reading 16bit samples at a rate of 22050 per sec, 
> so the data rate should be 22050*16/8=44100 bytes per second.

Ok

> But the rate actually is 8000 (you can check this by catting
> /proc/asound/card0/pcm0c/sub0/hw_params). In your  code:
> 
> res = 22050;
> if (ioctl(fd, SOUND_PCM_READ_RATE, 0xbfffdcfc) == -1)
> {
>    perror("ioctl");
>    exit(1);
> }
> printf("Sample rate: %d\n", res);
> 
> ... 'res' is always 22050 no matter what the device reports.

Ugh.  Now I am confused.  Since this is a speech recognition
program, I suppose it will perform a fourier transform (fft)
on the data.  When it expects a rate of 22050 (it requested
that and the ioctl confirmed it) then it will treat the data
as if it was 2.76 times higher in frequency then it actually
is!  That could lead to it not being able to understand the
spoken words, no?

> So with 8000, the date rate should be 16000 bytes/sec.

Ok, thats what I get more or less without any xruns.

> > Anyway, it seems too low or too high.
> > When I add back the "if (info.fragments > 0)" test
> > and decrease the naptime drastically, I get:
> 
> Try my other change to the test code - i.e. only sleep for
> naptime when info.fragments is zero.

That leads to no xruns, then it works.
It is of no use however because I can't get the closed
source application to read faster ;).

-- 
Carlo Wood <carlo@alinoe.com>


-------------------------------------------------------
This SF.Net email sponsored by: Parasoft
Error proof Web apps, automate testing & more.
Download & eval WebKing and get a free book.
www.parasoft.com/bulletproofapps1