Subject: Re: [linux-audio-dev] Making audio run realtime on older computers
From: Benno Senoner (sbenno_AT_gardena.net)
Date: Sun Jul 09 2000 - 15:51:13 EEST
On Sun, 09 Jul 2000, Twinkles wrote:> I am using a Linux 486DX66 to play audio but am experiencing the following
> problem to which a developer may be able to supply a solution.
I am not sure if a 486 @ 66Mhz is able to playback an MP3 128kbit in realtime.
(I owned a AMD 486_AT_133Mhz and had troubles too)
what you can try first is:
get a 128kbit mp3 file and figure out the len in seconds.
now do:
time mpg123 -w /dev/null yourfile.mp3
after decoding finishes , the output should look like this:
9.24user 0.08system 0:10.43elapsed 89%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (2016major+42minor)pagefaults 0swaps
get the elapsed time ( 10 sec in my case)
now divide this number through the playing len of the song.
(assume the song was 20sec long)
10/20 = 0.5 = 50% CPU usage
as long as this number is <0.9 realtime playback should be possible
now to the second issue: the usual linux lowlatency problems ..
on 486 HW there is a chance that your IDE disk doesn't support DMA,
or if it does (depends on the age of the disk/mainboard) you may corrupt
your data on your disk when activating DMA.
Without DMA there is no guarantee (but you can try) that you get dropoutfree
audio even by using the full 64KB buffer of your soundcard.
So the strategies are:
- use a multithreaded player which uses the full soundcard buffer.
- install the lowlatency patch ( only stable for 2.2.15)
( http://www.gardena.net/benno/linux/audio )
Although mpg123's decoding engine speed is great, the audio buffering sucks
quite a bit even on my Dual Celeron 366.
This is due to:
- no multithreading (audio and disk thread)
- uses a relatively small audio buffersize
try to use other mp3 players (xmms (run it as root and enable the realtime
flag) or others)
an alternative would be:
use mpg123 to output to stdout (-s) and pipe it through a small app
which :
fires up two threads :
- buffering thread which gets data from mpg123 (should be at least 500KB or so)
- audio thread which gets data via lock-free FIFO from the buffering thread
and runs SCHED_FIFO and uses the full 64KB of the soundcard buffer.
(I could produce such a small app in 20-30min but you know .. no time :-( )
PS: try the time mpg123 .... stuff .. it the factor is bigger than 0.9 then you
have simply to give up because your CPU is too slow to decode the MP3.
(an alternative would be first decode the mp3 to wav and then play it , but
I know it's too boring)
hope this helps.
Benno.
>
> I record some music to a WAV file at full cd quality 44100/2/16 and later
> save it as a MP3 at the same quality.
>
> I can play back the WAV perfectly. However, when I try to do the same with
> a MP3, if the sample rate is above 11025 it starts and stops once or many
> times every second. If I happen to be attempting to play the file via my
> stereo at a medium volume and forget the command line switch to
> downsample, the task switching nearly blows the speakers :(
>
> I know this is because the kernel is multitasking between the audio and
> the rest of the applications and the fact that MP3 has to be decoded while
> WAV is direct to the card but I am interested to know if there was any way
> to wrap the whole thing so the kernal thought it was to run to the
> exclusion of (almost) everything else.
>
> To get a mp3 to play I have to use either:
>
> mpg123 -4 file.mp3 (i.e. "-4" means downsampled twice to 11025)
>
> nice -19 mpg123 -4 file.mp3
This archive was generated by hypermail 2b28 : Sun Jul 09 2000 - 16:23:38 EEST