100Mbps wired Ethernet.Quote:
Originally Posted by Vincent Kars
Printable View
100Mbps wired Ethernet.Quote:
Originally Posted by Vincent Kars
Chris,
Does my top output not show 18% idle time?. it does go up when the SB Touch is refilling it's buffer, but I see on average 30% idle time when playing flac decoded on the SB touch (see screenshot).
I do have the Soundcheck mods applied, 3400us buffer, WLAN disabled, digital output only.
Regards,
Alex
Apologies Alex, you're right about 18% idle - I misread your output.:doh:Quote:
Originally Posted by AlexM
30% idle is in the same region as my results (35-45%, 20 sec sample rate). This does seem to vary dependant on what part of the file is being played. For the Mozart, I (generally) saw higher %idle earlier on.
The rest is the same as mine except I'm on 4000us buffersize.
Chris
Chris, Alex, you appear to be finding greater processing requirements for the hirez files but the reverse of what was expected? Is that correct?
But this is not so obviously the case for redbook?
Although this is no measure of the DAC's behaviour, it does imply the processing is stretching albeit for the reverse to what was considered likely.
Have either of you played the output to assess whether this results in any audible difference? Not better or worse, just audible...
Bob, the sirq-net-rx/0 process appears to cause the higher CPU requirements of PCM over FLAC on the SBT. This could be offsetting opposite effects in other processes. I'm NOT an expert but some googling does seem to suggest that this process is concerned with the network.Quote:
Originally Posted by bobbasrah
In retrospect, it would have been useful to compare %usr and maybe %sys. Something like 'sar' would have helped but I can't see it on the SBT.
Redbook files are smaller and don't seem to be stressing the SBT at all, PCM or FLAC.
Haven't done any listening comparisons of FLAC vs PCM. When I get a chance ....
Chris
Alex
Re msg 72 - thanks. You have confirmed what I hoped, that the FLAC designers did think about enough issues to make it all work, and that most implementers should therefore be able to produce encoders and decoders which will give a truly lossless compression/decompression.
I suppose it is not a requirement that two different compressors will produce the same output file given the same input, but it is a requirement that whatever the compressed file, all decoders should decode it to the same original file.
Basically,
For all audio files F which are compressible,
For all compressors C,
For all decompressors D,
D (C F) is exactly equal to F, where F is the input file.
If that is satisfied then the issue is not about the lossless data processing, but about performance issues which affect the playback, which seems to be the way the discussion is now going.
These look to be very high processor loads for Flac and WAV playback.
It might make this slightly more meaningful if the specification of the processor was given, the frequency of the side bus, the amount of RAM available, the amount of RAM in use and by what, and the South Bridge settings.
For SBT ?????:scratch:Quote:
Originally Posted by Welder
Are all the above using SBT and just SBT streaming?
(Just had a quick read and I see many are ;) )
Oh well, that rules the figures from my server irrelevant then ;)
No worries John,:)Quote:
Originally Posted by Welder
Despite my engineering background telling me to explore every possibility, and exhaust every avenue of investigation, at the back of my mind, I cannot help but reflect on your 100mph cyclist in the pub.....:steam: