Tír Na HiFi

Aleg wrote:I get the impression the answer is given from a bits-are-bits viewpoint from somebody who doesn't care about how the bits are delivered.

Aleg wrote:

jrling wrote:This post was on Squeezelite forum and although it is talking about Squeezelite on Linux, I guess the basic fundamentals apply to JLP on Windows?

Quote Originally Posted by soundcheck
Triode: One Q. The 2nd buffer parameter of -b x:x what is it exactly used for? Decoding? If that's the case it might make sense to make that value bigger then the streaming receive buffer - in case of streaming flacs.
In case of PCM it might be kept pretty small.
Could you please once more explain the logic behind -b x:x
=============================================
There are two buffers - the first one stores the raw stream (compressed) audio, the second the decode audio. PCM is a special case as the process of decoding is just unpacking samples into the second buffer so they are in 32bit format which is used in the output thread, but this is only a special case of decoding. The decode process thread runs whenever there is enough data in the first buffer and enough free space in the second one.

So if you want to stream the whole file at the start then probably make the first one big and keep the second one smaller (defaults at 10 seconds). If you want to stream and decode the whole file at the start then make the second one big.

The second buffer is really only needed to allow crossfade to happen and to separate the high priority output thread from the rest of the processing. Note that it uses 8 bytes per sample (2x32bits) whereas the first buffer uses the native sample rate and so will use less memory for the same amount of audio.

Would SBGK care to comment? Loading a whole track into RAM before playing (as an option by the appropriate buffer settings) would have good potential SQ implications?

Thanks
Jonathan

I get the impression the answer is given from a bits-are-bits viewpoint from somebody who doesn't care about how the bits are delivered.
I think from our earlier experiences it pays dividend how you choose values for those two buffer sizes.
If I read correctly the driver is fed from the second buffer (by portaudio routines) and there is a continuously running thread (in squeezelite) that converts data from the first buffer into the second buffer to keep that one filled up.

In that case the second buffer size should have some correlation with the buffer size set inside your driver,
or
would it be best to have a complete track loaded into the second buffer before playback starts so there would only be activity for transferring data from the second buffer into the driver buffer?

Looking forward to Gordon's comments

Cheers

Aleg

sbgk wrote: I've tried different sizes of streaming and decode buffers

large streaming buffer gives delayed start
small streaming sounded better
large decode sounded better
was able to have 2 tracks in memory and could play them repeatedly without lms running, don't know if more tracks could be loaded like this

the squeezelite architecture takes the highest quality ie wav and gives it the same treatment as the lowest, so not much hope of better sq without a bit of work, am going to try and get pa working on mqn to see if it's worth doing any more with squeezelite.

cvrle59 wrote:What does "pa" stand for here?
"am going to try and get pa working on mqn to see if it's worth doing any more with squeezelite."
Thanks

Aleg wrote:

cvrle59 wrote:What does "pa" stand for here?
"am going to try and get pa working on mqn to see if it's worth doing any more with squeezelite."
Thanks

Pa = portaudio.dll

tony wrote:Had a go at it earlier and thought it sounded flat. Tried Aleg's settings 300:8000 and it is nice and has detail but while it is good when I try 2.71 intel 1024 raw background it is not there yet. As somebody said if you never heard MQn it would sound excellent.
What is the difference between 2 and 4 core affinity? Has 2 emerged as the better bet? Sorry if the question is stupid.

Should add MQn is so much sharper(more deep detail) and has to me incredible depth in soundstage. I finally updated to C++ 2013 and maybe this has improved it all again. A few more tweaks and I will have to get Simon to bring his wadia brick over again for Round 3