* Bug in OSS simulation (ALSA 0.9.4)
@ 2003-07-10 1:33 Carlo Wood
2003-07-10 1:51 ` Carlo Wood
` (3 more replies)
0 siblings, 4 replies; 16+ messages in thread
From: Carlo Wood @ 2003-07-10 1:33 UTC (permalink / raw)
To: alsa-devel
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
^ permalink raw reply [flat|nested] 16+ messages in thread* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 1:33 Bug in OSS simulation (ALSA 0.9.4) Carlo Wood @ 2003-07-10 1:51 ` Carlo Wood 2003-07-10 22:54 ` Kai Vehmanen 2003-07-10 13:15 ` James Courtier-Dutton ` (2 subsequent siblings) 3 siblings, 1 reply; 16+ messages in thread From: Carlo Wood @ 2003-07-10 1:51 UTC (permalink / raw) To: alsa-devel; +Cc: xvoice 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 1:51 ` Carlo Wood @ 2003-07-10 22:54 ` Kai Vehmanen 2003-07-10 23:43 ` Carlo Wood 0 siblings, 1 reply; 16+ messages in thread From: Kai Vehmanen @ 2003-07-10 22:54 UTC (permalink / raw) To: Carlo Wood; +Cc: alsa-devel, xvoice 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 22:54 ` Kai Vehmanen @ 2003-07-10 23:43 ` Carlo Wood 2003-07-11 0:05 ` Kai Vehmanen 0 siblings, 1 reply; 16+ messages in thread From: Carlo Wood @ 2003-07-10 23:43 UTC (permalink / raw) To: Kai Vehmanen; +Cc: alsa-devel, xvoice 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 23:43 ` Carlo Wood @ 2003-07-11 0:05 ` Kai Vehmanen 2003-07-11 1:41 ` Carlo Wood 0 siblings, 1 reply; 16+ messages in thread From: Kai Vehmanen @ 2003-07-11 0:05 UTC (permalink / raw) To: Carlo Wood; +Cc: alsa-devel, xvoice 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-11 0:05 ` Kai Vehmanen @ 2003-07-11 1:41 ` Carlo Wood 0 siblings, 0 replies; 16+ messages in thread From: Carlo Wood @ 2003-07-11 1:41 UTC (permalink / raw) To: Kai Vehmanen; +Cc: alsa-devel, xvoice 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 1:33 Bug in OSS simulation (ALSA 0.9.4) Carlo Wood 2003-07-10 1:51 ` Carlo Wood @ 2003-07-10 13:15 ` James Courtier-Dutton 2003-07-10 22:36 ` Carlo Wood 2003-07-10 22:49 ` Kai Vehmanen 2003-07-10 23:09 ` Kai Vehmanen 3 siblings, 1 reply; 16+ messages in thread From: James Courtier-Dutton @ 2003-07-10 13:15 UTC (permalink / raw) To: Carlo Wood; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 13:15 ` James Courtier-Dutton @ 2003-07-10 22:36 ` Carlo Wood 0 siblings, 0 replies; 16+ messages in thread From: Carlo Wood @ 2003-07-10 22:36 UTC (permalink / raw) To: James Courtier-Dutton; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 1:33 Bug in OSS simulation (ALSA 0.9.4) Carlo Wood 2003-07-10 1:51 ` Carlo Wood 2003-07-10 13:15 ` James Courtier-Dutton @ 2003-07-10 22:49 ` Kai Vehmanen 2003-07-10 23:07 ` James Courtier-Dutton 2003-07-11 0:00 ` Carlo Wood 2003-07-10 23:09 ` Kai Vehmanen 3 siblings, 2 replies; 16+ messages in thread From: Kai Vehmanen @ 2003-07-10 22:49 UTC (permalink / raw) To: Carlo Wood; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 22:49 ` Kai Vehmanen @ 2003-07-10 23:07 ` James Courtier-Dutton 2003-07-11 0:00 ` Carlo Wood 1 sibling, 0 replies; 16+ messages in thread From: James Courtier-Dutton @ 2003-07-10 23:07 UTC (permalink / raw) To: Kai Vehmanen; +Cc: Carlo Wood, alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 22:49 ` Kai Vehmanen 2003-07-10 23:07 ` James Courtier-Dutton @ 2003-07-11 0:00 ` Carlo Wood 2003-07-11 0:21 ` Kai Vehmanen 1 sibling, 1 reply; 16+ messages in thread From: Carlo Wood @ 2003-07-11 0:00 UTC (permalink / raw) To: Kai Vehmanen; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-11 0:00 ` Carlo Wood @ 2003-07-11 0:21 ` Kai Vehmanen 0 siblings, 0 replies; 16+ messages in thread From: Kai Vehmanen @ 2003-07-11 0:21 UTC (permalink / raw) To: Carlo Wood; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 1:33 Bug in OSS simulation (ALSA 0.9.4) Carlo Wood ` (2 preceding siblings ...) 2003-07-10 22:49 ` Kai Vehmanen @ 2003-07-10 23:09 ` Kai Vehmanen 2003-07-11 0:28 ` Carlo Wood 3 siblings, 1 reply; 16+ messages in thread From: Kai Vehmanen @ 2003-07-10 23:09 UTC (permalink / raw) To: Carlo Wood; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-10 23:09 ` Kai Vehmanen @ 2003-07-11 0:28 ` Carlo Wood 2003-07-11 0:44 ` Kai Vehmanen 0 siblings, 1 reply; 16+ messages in thread From: Carlo Wood @ 2003-07-11 0:28 UTC (permalink / raw) To: Kai Vehmanen; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-11 0:28 ` Carlo Wood @ 2003-07-11 0:44 ` Kai Vehmanen 2003-07-11 2:03 ` Carlo Wood 0 siblings, 1 reply; 16+ messages in thread From: Kai Vehmanen @ 2003-07-11 0:44 UTC (permalink / raw) To: Carlo Wood; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: Bug in OSS simulation (ALSA 0.9.4) 2003-07-11 0:44 ` Kai Vehmanen @ 2003-07-11 2:03 ` Carlo Wood 0 siblings, 0 replies; 16+ messages in thread From: Carlo Wood @ 2003-07-11 2:03 UTC (permalink / raw) To: Kai Vehmanen; +Cc: alsa-devel 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 ^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2003-07-11 2:03 UTC | newest] Thread overview: 16+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2003-07-10 1:33 Bug in OSS simulation (ALSA 0.9.4) Carlo Wood 2003-07-10 1:51 ` Carlo Wood 2003-07-10 22:54 ` Kai Vehmanen 2003-07-10 23:43 ` Carlo Wood 2003-07-11 0:05 ` Kai Vehmanen 2003-07-11 1:41 ` Carlo Wood 2003-07-10 13:15 ` James Courtier-Dutton 2003-07-10 22:36 ` Carlo Wood 2003-07-10 22:49 ` Kai Vehmanen 2003-07-10 23:07 ` James Courtier-Dutton 2003-07-11 0:00 ` Carlo Wood 2003-07-11 0:21 ` Kai Vehmanen 2003-07-10 23:09 ` Kai Vehmanen 2003-07-11 0:28 ` Carlo Wood 2003-07-11 0:44 ` Kai Vehmanen 2003-07-11 2:03 ` Carlo Wood
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.