JLP wdm-ks player

[Julf]

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.

It is from the viewpoint of a Raspberry Pi, a very minimal linux computer that has a very different I/O and interrupt structure from a PC, and does a lot of things (that would be handled by dedicated hardware in a PC) in software. The raspberry pi also has an ARM processor - a very different CPU architecture compared to x86.

[sbgk]

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

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.

[Aleg]

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.

I also tried a few.

What I think I'm most pleased with is smallest stream buffer possible and a very large output buffer.

Am now listening to 260:8000 (255:8000 did work earlier but not now).
I feel this got some more clarity and additional depth. Esp. increasing the output buffer from 300 to 8000.
Am not completely sure though, as my hearing is not at its best at the moment (have a slight cold).

Cheers

Aleg

[cvrle59]

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]

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
Will give ks-capability

[cvrle59]

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

I should be using my brain these days.
Thanks Aleg!

[tony]

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 visual studio 2013 C++ runtime 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

[Aleg]

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

Tony

I'm glad the 300:8000 brought indeed an improvement for you as well. Did you go any lower on the 300? With me 260 and once 255 was the lowest I could go.

I have not put it besides MQn yet, but had the impression it gave an improvement in the right direction compared to 300:300.
BTW I am using -a 2 ms, TimerResolution 2 ms, DDC-buffer 2 ms and clockrate 23220.

Affinity 4 core sets affinity for squeezelite to 1 dedicated core and the rest to the remaing 3.
Affinity 2 is only different in that it sets the affinity of the rest of the programs to the one remaining core.

Cheers

Aleg

[tony]

Will have a go Aleg thanks for the explanation. 255 no sound but 260 plays ok.

[cvrle59]

I have a friend who owes "nicely loaded LP12" (CDS2 too) plugged into Naim 52/135's, who was stating that computer will never produce "non-digital" feel. He had to swallow his words, when he visited me just before Christmas. He could not believe it. He was always underestimating digital music streaming, without any kind of interest in it, but last time, he was asking me millions of questions.
Something to do with MQn, I guess..
I was joking telling him, that "my LP12" doesn't have an arm, but I still have to stand up to make it play...lol.