From alsa-devel-owner@alsa.jcu.cz  Fri Mar 12 19:30:28 1999
Received: from galjas.cs.vu.nl (root@galjas.cs.vu.nl [130.37.24.13])
	by marvin.jcu.cz (8.9.1a/8.9.1) with ESMTP id TAA00166
	for <alsa-devel@alsa.jcu.cz>; Fri, 12 Mar 1999 19:30:20 +0100
Received: from localhost by galjas.cs.vu.nl with esmtp
	(Smail3.1.28.1 #49) id m10LWhO-0006N9C; Fri, 12 Mar 99 19:30 +0100
Date: Fri, 12 Mar 1999 19:30:18 +0100 (MET)
From: Andy Lo A Foe <arloafoe@cs.vu.nl>
To: T.Mertes@mobilkom.at
cc: alsa-devel@alsa.jcu.cz
Subject: RE: Enlarging the dma buffer for audiopci (fwd)
In-Reply-To: <48A7CB4095A7D11187EF00609748374C02F161B2@w1sxms01.mobilkom.at>
Message-ID: <Pine.GSO.4.10.9903121910590.2380-100000@galjas.cs.vu.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: alsa-devel@alsa.jcu.cz
Sender: alsa-devel-owner@alsa.jcu.cz
Precedence: list

On Fri, 12 Mar 1999 T.Mertes@mobilkom.at wrote:

> 	I think you missunderstand something. The problem is:
> 	When the sound playing program is waiting for the read() system
> 	call the sound driver runs out of data. This is not because of a
> 	sound driver problem or a problem of the sound playing program
> 	or its priority.

If this is the case, then its most likely a design problem with the
program in question. From what I understand now (please tell me if I miss
the point again :) this means that the program is using just one 
single process to read data from disk *and* write data to the soundcard,
right? This makes it quite impossible to achieve skip-free playback under
heavy load and no amount of driver hacking will fix this.

> 	You can have the best driver with the smartes buffering and the
> 	trickiest sound playing program under the highest RT priority.
> 	If the sound playing program has to wait for a disk read() this
> 	does not help at all. The sound playing program waits for (for
> 	example) two seconds for the read() system call to complete.
> 	Very high disk load can make this happen. Have you ever tried
> 
> 	  find / -name "*core*"

For the fun of it I just tried it to test the RT performance (and the
design *g*) of the prgoram I'm working on. Here is a dump of
/proc/asound/card1/pcm0 after I ran the above find command while playing
an MP3 in realtime (an typing this mail over ssh :)

[arloafoe@orbital ~]$ cat /proc/asound/card1/pcm0
DSP v4.16

Playback
  Mode           : native
  Format         : Signed 16-bit Little Endian
  Rate           : 44100Hz [requested 44100Hz]
  Channels       : 2
  Buffer size    : 131072
  Buffer used    : 131072
  Fragments      : 32
  Fragment size  : 4096
  Fragments room : 1
  Fragments max  : 5
  Underruns      : 0
  Total underruns: 5
Record isn't active.

As you can see this shows you that there were zero underruns. This is
while searching approx. 10Gigs of hard disk space spread over ext2 and
vfat filesystems. The only thread that was scheduled RT was the one that was
feeding the soundcard (snd_pcm_write(...)). The thread that was decoding
the MP3 didn't even need to be scheduled RT since there is a sufficient
buffering mechanism (300KB). If read() can block for 2 seconds or longer
you would need to increase the decoding/reader buffer to accomodate for
this long a pause (you can happilly buffer a few megabytes if you want).
Again, this is more of a design issue of the USER program and it really
makes no sense to try and fiddle with the kernel driver your case.
The above dump also shows you that the program is effectively only using
about 20K (5 * 4096) bytes of the DMA buffer. 
You can get source code of the test program at:
http://alsa.jcu.cz/alsa/people/andy
Comments are always welcome of course :)

> 	while playing a wave sound file. Of course your dentry cache
> 	must be clean to put real load on the disk. Have you compiled
> 	your new kernel while playing sound. Or do both (from X11 of
> 	course) while doing also Netscape/Xemacs and other DISK and
> 	CPU load on the system. If you still have no dropouts please say
> 	to me which soundcard, driver, and wave file playing software
> 	you use.

Soundblaster AWE64 Gold ISA. I have had much better results with PCI cards
of course (AudioPCI). I tried just about anything that can generate heavy
load on my machine (make dep clean bzlilo modules modules_install WHILE
playing mp3's, not a single skip :). I'll be adding WAVe support to the
alsaplayer program real soon so you will be able to test for dropouts on
WAV files (probaby next week as I'm quite busy with school 'n stuff)

> 	I think with PCI DMA you don't have this limitation. You missed
> 	this point also.

I don't think I did. A driver solution would have to work for both ISA
*and* PCI cards. That means you'll have to take into account the 16MB
limit that ISA cards have. A solution that relied on allocating more than
16MB *in* the kernel would be really silly and will probably not be
accepted by anyone :)

> 	Greetings Thomas

Regs,

Andy
--
Andy Lo A Foe, arloafoe@cs.vu.nl |   Linux v2.2.2   | PII 266 
http://www.cs.vu.nl/~arloafoe    |    ALSA 0.3.0    | Bebox 133
http://orbital.xs4all.nl/andy    |  IRCNet: adnans  | DVD freak


