JLP music player

[jrling]

Just got round to listening to v.22 & v.24 of JLP.

 

For me, V.22 was a bit 'thin' - definitely lacked bass and a bit harsh on detail at top end. Even a tiny bit of ear pain, which I have not had for ages.

 

V.24 though was a revelation. Lovely taut bass underpinning beautiful mid-range and dynamic top end. Very pleasing. A keeper.

 

Thanks

Jonathan

[jrling]

Yep, as soon as I heard pa v20 for the first time I knew it was a big step forward. Will be interesting if I can tease any more out of it using the same techniques. It's a very pleasant revealing sound that just demands to be listened to.

 

+1 (v.26).

 

Just sublimely listenable; detail and smoothness all in one. Beats MQn on my system.

 

Thanks Gordon

[jrling]

Sounds excellent (like previous version).

 

+1

[jrling]

There seems to be a thinness about the sound though, maybe need to revisit the changes. Have started using -a 10 ie 10ms as that is equivalent to MQn 448, shall try 23 as well as that is near 1024 samples at 16/44. In theory KS should be better than wasapi because wasapi is a wrapper for ks, but maybe need to get nearer to the core ks code to hear it.

 

Hi Gordon

 

I am keen to try other settings, as some can have distinct effects - better and worse - on SQ.

 

However, I feel that I am really just staggering around in the dark guessing what to try and would much prefer to have some logical empirical reasoning behind settings. As I sure that you do from the sound of this post.

 

Not knowing how your code works, would you be able to elucidate further on both -a and -b recommended settings.

 

I have a nasty feeling though that system-specific factors will come into play.

 

Thanks as always

 

Jonathan

[jrling]

these are squeezelite settings, -a is latency in ms so the end device uses this latency which affects the no of samples in the buffer. -b has 2 parameters -b x:y eg -b 1000:2000, x is the decode buffer in kb and y is the output buffer in kb. Triode gave some information recently in the slimforums squeezelite thread about the interaction between the buffers. Best to try your own experimental settings or see what others are using.

 

Thanks for the clear explanation, which I was sort of aware; I will check Triode's post.

 

But it is the understanding of how your render loop interacts with those settings that I don't have any clue. Have tried -a 10 and 23 and they both sound good, but not any discernable difference between the two. WaveIO (TheSycon driver) quotes its latency as xx ms per 2 buffers - do you think therefore that your -a 10 and 23 should be halved or is it doubled?!

 

Do you have any pointers as the best decode buffer size from your render loop?

 

Trouble is with experimenting with three settings, is that they can all interact with each other and the possible permutations are endless - unlike my time unfortunately.

[jrling]

For others' benefit - here is Triode's helpful clarification of the -b buffer settings, although he was talking about the Linux version of Squeezelite and not Windows -

 

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.

 

It does however raise a number of questions that I cannot answer. First off, I think JLP is basically Local Player based and so streaming is not being processed. Secondly, the settings could easily need to be quite different depending on whether one is playing PCM (WAV files) or FLAC (being decoded by JLP). Thirdly, I doubt that many JLP users are using Crossfade and I doubt Gordon would let them in his code!

 

Plenty for me to experiment with then. I play WAV files mostly. I would be happy to load the whole track before playing (Memory Player) even if it delays play slightly, as I guess that is going to give better SQ than loading the buffer continuously.

 

Lastly, I suppose that having very large -b settings, and assuming one has sufficient RAM to hold the data in memory, might place more strain on the CPU, but if that is only taking place once before play commences, then that's fine if it reduces CPU activity during actual play itself. I will try.

[jrling]

Well I tried -b 100000:100000 and wow. It was as though everything snaps into focus. Lovely taut bass and beautifully relaxed but detailed. Full harmonic richness brought out. Definitely the best yet for me. Using -a 10.

 

I am guessing that this setting does mean it is a full memory load before play, as the SSD red light did not come on once during the track.

 

Of course YMMV. I have a low powered Atom PC, so it may not be the same for others.

 

Would be interested if others have tried that setting and their findings.

 

Thanks again Gordon.

[jrling]

It seems I'm on a hiding to nothing releasing interim versions, at this stage all I'm trying to do is convince myself that there's something worth persuing SQ wise in jlp ie ks over wasapi.

 

I certainly don't feel that way and appreciate, as always, the results of your obviously intensive time spent on development for us to enjoy.

 

I suspect that many others do as well, even if they don't say so.

 

My personal feedback is that what you have done with SqueeezeLite, is to turn it into the best player that I have experienced and a truly amazing result.

 

For me, the only regret is the gradual deprecation of various SqueezeLite functionality such as Volume, Progress Bar & and now Pause; all in the cause of SQ of course, but IMHO that approach takes away from the experience of why I turned to SqueezeLite in the first place from MQn. I also suspect that those removals do not make material difference to SQ.

 

I would like to suggest that these SqueezeLite features are restored at some future point, or there is a second build that includes them, and that the 'hair shirt' approach to a minimal player (with KS) is taken forward on MQn.

 

Well that's my position. What do others think?

 

Thanks

 

Jonathan

[jrling]

If removing some functions (like pause) is one of the sacrifices that needs to be made to move ahead and get better sound, than so be it.

Whoever does not want that can use the previous version(s) that have that particular function still working.

 

It's a choice, or compromise......like everything else!

Totally agree that life is a compromise, but my point was that it is possible to have both, if SBGK is good enough (when dev has been finalised) to compile versions of JLP that do and do not have full Squeezelite functionality.

 

Also surely if you are aiming 100% for SQ at the expense of any functionality, then you will go for MQn? SBGK is after all only playing with SqueezeLite to learn how Portaudio does KS and will at some stage move to generating MQn code using KS (with or without PA). Or at least that is what I understand is his plan one day.

 

Jonathan

[jrling]

Well I certainly got a lot of bang for my buck in your reply! As you know, I am a dim Accountant and so the code means nothing to me.

 

I can see loads of commenting out, but also loads of it seem to relate to removal of DSD (good), ReplayGain (good) and CrossFade (good) and not per se the little ole Volume Slider.

 

Perhaps I was not clear. I am not criticising removal of redundant code - I applaud it; but when it starts to impinge on Squeezelite base functionality, then I do question it - if one is modifying Squeezelite. Particularly, since Triode/Logitech with LMS 7.8, provide disabling settings for Volume ('Set at Fixed 100%"), Disable CrossFade and ReplayGain check boxes. Do they not have the same effect for the majority of users it appears who willingly sacrifice those facilities in Squeezelite? I think I can guess your answer! Bet noone has tested that though with their ears.

 

BTW, anyone who says losing 1 bit of 16 bits resolution (playing 16/44.1) by using Volume Control is going to compromise SQ detectably, has a different technical understanding of how DAC technology works to me. I read that most DACS at best get 12 bits of actual usable resolution and that's a really good DAC. But I bet noone will agree with me on that either.

 

Hey Ho. Where is everyone else?

 

Jonathan

[jrling]

I am "JLp V30/31 handicapped". I doesn't work on my system at all...sorry Jonathan.

Sorry to hear that. What's the cause or don't you know?

 

I know that I will get flak, but in my system, which is pretty resolving, I am not getting much noticeable changed SQ with the v30/31.

 

I guess that Gordon will feel that most low-hanging fruit has already been picked, and the law of diminishing returns is beginning to kick in.

 

The removal of streaming functionality, which I regard as totally consistent with a 'Local Player' application, will be the 'next big thing'.

 

Jonathan

[jrling]

wouldn't say removal of streaming would achieve anything, really need to break the non streaming part out so it plays from memory like mqn does.

 

I thought that Triode said using large values in the -b setting had the effect of loading the complete track into memory before play?

 

yup, you also said you couldn't hear any difference between 10 and 23 latency, so room for improvement.

 

Well may be or perhaps that is the actual position with my rig. It is Atom-based and that might behave differently. Or I could lie if that would help!

[jrling]

Just a quick reply, without going into massive detail. And no, I wont be drawn into a debate about the best DAC chip, this is not what this post is about.

 

Older DAC chips such as TDA1541A and PCM58,63,1702,1704 have very good linearity.

From what I've read, the TDA1541A can generally reproduce 15.5 bits accurately. The Burr brown 18-24 bit chips can reproduce at least 16bits accurately. The 24 bit versions can probably do at least 18 bits without breaking a sweat. More modern delta sigma 24bit chips have been measured to reproduce 14-16 bits accurately. Im sure the ES9018 will easily do 16 + bits.

 

The interesting point to debate comes down to the individual implementation of the power supples on the DAC PCBA. Does the power supply provide at least -96dB of noise in order for the DAC to produce the full 16bits... food for thought. The other consideration is signal to noise ratio of both a live performance, whether that be a solo guitarist playing in their bedroom or attending a rock concert. Background noise is always there! Only anechoic chambers and other surreal specially constructed rooms come close to zero background noise. Im happy to argue that 90dB signal to noise is perfectly acceptable.

16 bit recordings acheve this.

 

IMO sample rate is the bigger concern. 48khz should be the minimum and 88.2khz the maximum required -ever! Recordings are made for humans not bats. Oh but harmonics... yes I still will argue that 88.2khz is the highest we need. Any more is a waste.

 

I think your generalisation that DACs only make use of 12 bits is a little wrong. It may apply to some chips, but I doubt these are the sorts of chips the average audiophile is using these days. Perhaps something out of a cheap 1990's walkman, or cheap car CD player?

 

With regard to volume control. Some will hear it, some wont. Depends on the gear in the audio chain. Those that can hear it will find a noticable worthwhile improvement, those that cant, will wonder why the functionality has been removed.

 

Erin - thanks for the most informative, polite and helpful reply. I can accept everything you say.

 

At risk of spoiling it though (!), if one is using a 24 bit DAC chip which i guess most are these days, is it not the case that playing 16/44.1 recordings, there are 8 bits that are full of zeros padded out? if so, surely, the digital volume control is only removing the unused zero values for up to 8 bits - and that's assuming a 16 bit resolution is achieved by the DAC?

 

That was my understanding and if correct, then a digital volume control would not cause loss of resolution.

 

I continue to believe that there is a trade-off of convenience and ultimate SQ, and even Gordon agreed on one forum that the ability to easily explore one's music collection was probably the most important aspect of a player; my findings are that tracks on a CD and certainly between different CDs are not level matched and with my sensitive speakers anyhow, I have to keep on getting up to adjust volume which gets tedious. But I am 64!