diyAudio

diyAudio (http://www.diyaudio.com/forums/)
-   PC Based (http://www.diyaudio.com/forums/pc-based/)
-   -   Considering old hardware for an audio player/recorder (http://www.diyaudio.com/forums/pc-based/192651-considering-old-hardware-audio-player-recorder.html)

Onvinyl 15th July 2011 12:13 PM

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

phofman 18th July 2011 01:06 PM

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

Onvinyl 18th July 2011 01:28 PM

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

phofman 18th July 2011 01:52 PM

Quote:

Originally Posted by Onvinyl (Post 2642645)
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)

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

Quote:

Originally Posted by Onvinyl (Post 2642645)
At the moment, MPD talks to a RME digi96/8 via hw:0,0 directly

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).

Onvinyl 18th July 2011 02:29 PM

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

phofman 18th July 2011 03:31 PM

Quote:

Originally Posted by Onvinyl (Post 2642673)
Hm, whatever value I give as -B aplay always uses 16384 as buffer_size...


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 8192

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?

Onvinyl 18th July 2011 04:23 PM

OK, here ist aplay#s output if no -B value is given:
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      : 0

This 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      : 0

This 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      : 0


phofman 18th July 2011 07:04 PM

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 :-)

Onvinyl 18th July 2011 07:52 PM

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:

phofman 18th July 2011 08:38 PM

Quote:

Originally Posted by Onvinyl (Post 2642983)
EDIT: OK, I found it. The smallest amount is around 95 counts per second, the worst but still working is around 500.

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)

Quote:

Originally Posted by Onvinyl (Post 2642983)
Sonics? I wasn't aware of the machine building a kernel while playing music the other day... :eek:

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


All times are GMT. The time now is 01:24 AM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright ©1999-2014 diyAudio


Content Relevant URLs by vBSEO 3.3.2