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
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
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
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).
The source code (rme96.c) says:
Code:
/* Playback and capture buffer size */
#define RME96_BUFFER_SIZE 0x10000
....
/* Block sizes in bytes */
#define RME96_SMALL_BLOCK_SIZE 2048
#define RME96_LARGE_BLOCK_SIZE 8192I.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:
Code:
# aplay -D hw:1,0 Clytus*.wav -f cd -v
Wiedergabe: WAVE 'Clytus Gottwald - Hector Berlioz - Sur les lagunes.wav' : Signed 16 bit Little Endian, Rate: 44100 Hz, stereo
Hardware PCM card 1 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 2048
period_time : 46439
tstamp_mode : NONE
period_step : 1
avail_min : 2048
period_event : 0
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0This is for very small value:
Code:
aplay -D hw:1,0 Clytus*.wav -f cd -v -B 4
Wiedergabe: WAVE 'Clytus Gottwald - Hector Berlioz - Sur les lagunes.wav' : Signed 16 bit Little Endian, Rate: 44100 Hz, stereo
Hardware PCM card 1 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 512
period_time : 11609
tstamp_mode : NONE
period_step : 1
avail_min : 512
period_event : 0
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0This a very big one:
Code:
aplay -D hw:1,0 Clytus*.wav -f cd -v -B 64k
Wiedergabe: WAVE 'Clytus Gottwald - Hector Berlioz - Sur les lagunes.wav' : Signed 16 bit Little Endian, Rate: 44100 Hz, stereo
Hardware PCM card 1 'RME Digi96/8 PST' device 0 subdevice 0
Its setup is:
stream : PLAYBACK
access : RW_INTERLEAVED
format : S16_LE
subformat : STD
channels : 2
rate : 44100
exact rate : 44100 (44100/1)
msbits : 16
buffer_size : 16384
period_size : 512
period_time : 11609
tstamp_mode : NONE
period_step : 1
avail_min : 512
period_event : 0
start_threshold : 16384
stop_threshold : 16384
silence_threshold: 0
silence_size : 0
boundary : 1073741824
appl_ptr : 0
hw_ptr : 0Sorry, 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 🙂
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... 😱
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... 😱
Last edited:
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.
That's what it says:
The number you see is increasing 95 counts every second.
It just doesn't get lower. I set period_time as high as 100000000000 in mpd.conf
It does not get better than 43 counts with 16/44
Rüdiger
Code:
5: 1001726 XT-PIC-XT RME96The number you see is increasing 95 counts every second.
It just doesn't get lower. I set period_time as high as 100000000000 in mpd.conf
It does not get better than 43 counts with 16/44
Rüdiger
OK. Perhaps MPD has some internal boundaries for ratio between buffer and period sizes. You can check the actual values set by the player in the file /proc/asound/card1/pcm0p/sub0/hw_params (provided your card has ID 1).
And it perfectly fits the RME96_LARGE_BLOCK_SIZE in http://www.diyaudio.com/forums/pc-b...rdware-audio-player-recorder.html#post2642730 . This is the largest period your sound card allows. Let's see:
( 44100 Hz x 2 bytes x 2 channels ) / 8192 bytes = 21.5 IRQs (i.e. processed periods) per second
What format does that hw_params file list? If MPD sent S32_LE (i.e. 4 bytes instead of the 2 in the calculation above), we would get 43 IRQs/s which is your number.
Anyway, now you have verified that MPD is set up for both the largest buffer and period your card supports. That is the lowest CPU load you can achieve from your playback chain. Congratulations 🙂
Somehow youre right 🙂 right now, it uses around 20 counts.
I spend quiet some time last year to get behind mpd.conf so I'm happy it proved right again now....
What I would really like to try is to do some tweaks with the psu. Are the power lines for drives, cpu, peripheral devices separate? So I could provide some voltages from a linear psu?
Rüdiger
I spend quiet some time last year to get behind mpd.conf so I'm happy it proved right again now....
What I would really like to try is to do some tweaks with the psu. Are the power lines for drives, cpu, peripheral devices separate? So I could provide some voltages from a linear psu?
Rüdiger
Well, the PCI card is powered from the MB. It uses +12V, +5V, +3.3V, probably -12V too, all these voltages are available on the PCI bus. Theoretically you could cut the corresponding traces/remove the voltage regulators on your card and provide these voltages from different PSUs. Practically, it would be quite a chore 🙂
Well, you can power your HDs from a different PSU. I would doubt the effect though.
My Q wasn't clear. The ATX Powerplug has 20 poles with multiple 3.3V, pathes. Are these seperate? and routed to different devices? Or are they multiples of the same line to enforce power capability of cables and contacts?
Rüdiger
Rüdiger
I have disassembled many PSUs (mostly dead ones 🙂 ) and wires of the same color (i.e. voltage) have always been soldered to a single junction.
Hi,
I could do with some help. My ancient fujitsu machine is dead. Since I'am a bit short at the moment, I swapped the RME Digi96 in another machine, which runs the same linux distro (Gentoo).
Amazingly, it does not work in 24bit mode here. I have to use 16 bit. If I try to call sox in 24bit, for instance, I get
The driver is kernel built-in.
EDIT: Progress! I used to call sox by means of sox -b 32 -t alsa hw:0,0 (...)
That doesn't work no more. It works now if I type
sox -b 24 -t alsa plughw😛ST ...
The only difference I can think of is, that I uninstalled dmix on the old machine, but forgot (about) it now.
Rüdiger
I could do with some help. My ancient fujitsu machine is dead. Since I'am a bit short at the moment, I swapped the RME Digi96 in another machine, which runs the same linux distro (Gentoo).
Amazingly, it does not work in 24bit mode here. I have to use 16 bit. If I try to call sox in 24bit, for instance, I get
Code:
sox FAIL formats: can't open input `hw:0,0': select_format error: Operation not permittedThe driver is kernel built-in.
EDIT: Progress! I used to call sox by means of sox -b 32 -t alsa hw:0,0 (...)
That doesn't work no more. It works now if I type
sox -b 24 -t alsa plughw😛ST ...
The only difference I can think of is, that I uninstalled dmix on the old machine, but forgot (about) it now.
Rüdiger
Last edited:
Look at the driver, method snd_rme96_capture_setformat git.alsa-project.org Git - alsa-kmirror.git/blob - pci/rme96.c . Only S16_LE and S32_LE formats are supported natively. If you want to use other formats, you have to use the plug plugin (plughw). Therefore, in sox you either have to specify -b32, or have to use the plughw:0 device. The result is equivalent - in the first case sox does the 32/24 bit conversion (no data is lost, the card uses only 24 bits of the 4 bytes anyways), in the second case the plug plugin does the conversion, feeding 3byte format to sox.
There is no reason to avoid/be afraid of the plug plugin, it does only the minimum conversions needed.
There is no reason to avoid/be afraid of the plug plugin, it does only the minimum conversions needed.
- Status
- Not open for further replies.