Considering old hardware for an audio player/recorder
 

Hi,
I use an old Siemens Scaleo 400 for audio (playback and analog recording or vinyl playback). I use mpd for playback, which runs on a linux gui-less os with a custom lean kernel. Sox for recording/vinyl De-RIAA-ing. The musicfiles are coming from a central file server, and i use a rme soundcard along with a ADI-2 from RME as well.

Pretty nice, but probably to better.

- First thing to try is feeding the ADI-2 with batteries (or shunt reg or whatever). If I'm brave I'd might skip the internal power conditioners, but I did not look inside if that's possible at all.

- Have the os running from an usb-stick, though I'm not sure if using the usb bus is better than the IDE channel (no sata on that machine), or if the hard drive pollutes audio more than marginally at all -- it seldom runs when the machine has booted and anything is started.

- Get an Intel networkadapter, that doesn't use so much cpu-time (as opposed to realtek)

- switch off anything in BIOS I don't need, undervolt (if possible)

- Replace some voltages with linear psu modules. Here I have a problem: Which voltages on a 20-pol ATX power plug could and should be replaced? How to configure ground? Anyone tried to partly replace a PC-PSU for such an old board?

- Anything else I should consider (apart from new hardware?)

Rüdiger

Which distribution are you running? Which output sound device does your MPD use?

Hi,
I run gentoo with a realtime kernel 2.6.33.7.2-rt30 #3 PREEMPT RT
(as you might know, gentoo is a distri where each and any peace of software is compiled at the target machine, leading to optimized and hopefully faster code)

At the moment, MPD talks to a RME digi96/8 via hw:0,0 directly
Alternativly I can pipe to brutefir, but I have no useful filters as of know.
When recording anlog sources, I'm using sox

Rüdiger

Hopefully :) Well, gentoo on lower-power machines makes sense.

Good, the shortest route possible.

Do you care about your playback latency? If not, you can try to set buffer_time as large as possible, and period_time about 1/8 of that. The easiest way to find out for your card is to play with parameters -B and -F of aplay, outputing to hw:0,0 while playing your wavs. Just use insanely large values, aplay in verbose mode (parameter -v ) will tell you the largest available value. While playing with the period time parameter, you can check /proc/interrupts to see how number of IRQ/s by your card grows/plunges (watch -n 1 grep "YOUR CARD MODULE NAME" /proc/interrupts).

You want to minimize wakeups of your playback software (buffer time - how often the SW fills RAM with new samples for DMA) and reasonably minimize IRQs (how ofter the card tells the driver that it has finished reading samples in the previous segment of RAM).

Hm, whatever value I give as -B aplay always uses 16384 as buffer_size...

The source code (rme96.c) says:

I.e. the max buffer size should be 65kB, period size between 2048 and 8192. Are you sure you are giving correctly formatted values? What is the command and its output?

OK, here ist aplay#s output if no -B value is given:
This is for very small value:
This a very big one:

Sorry, the parameter is --buffer-size=xxxx and --period-size=xxxxx

The value xxxx is number of frames, plain number, no units. E.g. --buffer-size=65536

Nevertheless, the maximum number you can get is still your 16384. It is number of samples, each sample is 2 bytes, times 2 channels - exactly 16384 x 4 = 65536 bytes :)

The parameter I talked about in MPD is not in samples, but in microseconds. The buffer size is fixed, but buffer time depends on sample rate and sample format (16/24). The MPD documentation says the default buffer time value is 0.5s. Internally, the player calls alsa API function which returns the closest accepted buffer-time value accepted by your particular hardware (i.e. driver). And in your case it is always lower, e.g. for 44100kHz we are getting maximum buffer time of 16384/44100 = 0.372s.

To conclude, raising the buffer_time parameter in MPD above the default 500000 will not make any difference. You can play with period_time though. It is set rather low in MPD. Good for playback under load, a little bit pessimistic for lightly-used machines. While raising it you should see the corresponding reduction in IRQs, lowering the CPU load. But I doubt you will hear any sonic difference :-)

I have a hard time guessing the correct card name for 'watch...' however, whatever value i set for period_time (even unsane high ones) does not change mpd's cpu load (around 9%)

Rüdiger

EDIT: OK, I found it. The smallest amount is around 95 counts per second, the worst but still working is around 500. Sonics? I wasn't aware of the machine building a kernel while playing music the other day... :eek:

What does the grepped line say? 95 IRQs per second is still pretty high, you should be able to drop it down to 10-15 ( 1/(0.378s /4) = 10.5 IRQs per second for the largest buffer size/time, 44100/16 track and 4 periods per buffer (i.e. the player is awoken 4 times until the whole ring buffer is played, to refresh the already played periods/segments with new data)

:-) How come I tend to believe you? :-) But the drive seeks really pollute the supply lines with ugly noise.