JLP music player

[sima66]

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!

[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

[sbgk]

love google translate

 

May reduce both the left part of the cause,

but because the issue is too complex, there are too many factors influence,

I'm afraid the net system by a reclock cant get all the problems solved,

if you agree and family outside catching rabbits reclock both machines have the microphone WINNER? I And feel free home by rational analysis may be perfect, for example: a USB cable can seriously affect the sense of hearing, they can change a power cord of both worlds, with a harddisk read and read with the use of USB Flash contention far away, so you can only rely on their own happy to hear receipt ~

 

from JLP Player + Windows Server 2012 R2 + Fidelizer + FREE!!! -

[sbgk]

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

 

here is the volume code which I have commented out (the // lines), think you can see why I didn't want it running. The pause disable was only in v29b.

 

frames_t _output_frames(frames_t avail) {

 

 

frames_t frames, size;

bool silence;

 

/*s32_t cross_gain_in = 0, cross_gain_out = 0; s32_t *cross_ptr = NULL;

 

s32_t gainL = output.current_replay_gain ? gain(output.gainL, output.current_replay_gain) : output.gainL;

s32_t gainR = output.current_replay_gain ? gain(output.gainR, output.current_replay_gain) : output.gainR;*/

 

frames = _buf_used(outputbuf) / BYTES_PER_FRAME;

silence = false;

 

// start when threshold met output.threshold

//if (output.state == OUTPUT_BUFFER && frames > output.threshold * output.next_sample_rate / 100 && frames > output.start_frames) {

// output.state = OUTPUT_RUNNING;

// //LOG_INFO("start buffer frames: %u", frames);

// printf("%u", frames);

//

// wake_controller();

//}

//printf("%u", frames);

// skip ahead - consume outputbuf but play nothing

/*if (output.state == OUTPUT_SKIP_FRAMES) {

if (frames > 0) {

frames_t skip = min(frames, output.skip_frames);

LOG_INFO("skip %u of %u frames", skip, output.skip_frames);

frames -= skip;

output.frames_played += skip;

while (skip > 0) {

frames_t cont_frames = min(skip, _buf_cont_read(outputbuf) / BYTES_PER_FRAME);

skip -= cont_frames;

_buf_inc_readp(outputbuf, cont_frames * BYTES_PER_FRAME);

}

}

output.state = OUTPUT_RUNNING;

}*/

 

// pause frames - play silence for required frames

/*if (output.state == OUTPUT_PAUSE_FRAMES) {

LOG_INFO("pause %u frames", output.pause_frames);

if (output.pause_frames == 0) {

output.state = OUTPUT_RUNNING;

} else {

silence = true;

frames = min(avail, output.pause_frames);

frames = min(frames, MAX_SILENCE_FRAMES);

output.pause_frames -= frames;

}

}*/

 

// start at - play silence until jiffies reached

/*if (output.state == OUTPUT_START_AT) {

u32_t now = gettime_ms();

if (now >= output.start_at || output.start_at > now + 10000) {

output.state = OUTPUT_RUNNING;

} else {

u32_t delta_frames = (output.start_at - now) * output.current_sample_rate / 1000;

silence = true;

frames = min(avail, delta_frames);

frames = min(frames, MAX_SILENCE_FRAMES);

}

}*/

 

// play silence if buffering or no frames

if (output.state <= OUTPUT_BUFFER || frames == 0) {

silence = true;

frames = min(avail, MAX_SILENCE_FRAMES);

}

 

 

//LOG_SDEBUG("avail: %d frames: %d silence: %d", avail, frames, silence);

frames = min(frames, avail);

size = frames;

 

while (size > 0) {

frames_t out_frames;

frames_t cont_frames = _buf_cont_read(outputbuf) / BYTES_PER_FRAME;

int wrote;

 

if (output.track_start && !silence) {

if (output.track_start == outputbuf->readp) {

frames -= size;

//IF_DSD(

// if (output.dop != output.next_dop) {

// if (output.dop_delay) {

// // add silence delay in two halves, before and after track start and pcm-dop change

// if (!output.dop_delay_active) {

// output.pause_frames = output.current_sample_rate * output.dop_delay / 2000;

// output.dop_delay_active = true; // first delay - don't process track start

// break;

// } else {

// output.pause_frames = output.next_sample_rate * output.dop_delay / 2000;

// output.dop_delay_active = false; // second delay - process track start

// }

// output.state = OUTPUT_PAUSE_FRAMES;

// }

// }

// output.dop = output.next_dop;

//)

//LOG_INFO("track start sample rate: %u replay_gain: %u", output.next_sample_rate, output.next_replay_gain);

output.frames_played = 0;

output.track_started = true;

output.current_sample_rate = output.next_sample_rate;

// if (!output.fade == FADE_ACTIVE || !output.fade_mode == FADE_CROSSFADE) {

//output.current_replay_gain = output.next_replay_gain;

// }

output.track_start = NULL;

break;

} else if (output.track_start > outputbuf->readp) {

// reduce cont_frames so we find the next track start at beginning of next chunk

cont_frames = min(cont_frames, (output.track_start - outputbuf->readp) / BYTES_PER_FRAME);

}

}

 

 

/* IF_DSD(

if (output.dop) {

gainL = gainR = FIXED_ONE;

}

)

*/

//if (output.fade && !silence) {

// if (output.fade == FADE_DUE) {

// if (output.fade_start == outputbuf->readp) {

// LOG_INFO("fade start reached");

// output.fade = FADE_ACTIVE;

// } else if (output.fade_start > outputbuf->readp) {

// cont_frames = min(cont_frames, (output.fade_start - outputbuf->readp) / BYTES_PER_FRAME);

// }

// }

// if (output.fade == FADE_ACTIVE) {

// // find position within fade

// frames_t cur_f = outputbuf->readp >= output.fade_start ? (outputbuf->readp - output.fade_start) / BYTES_PER_FRAME :

// (outputbuf->readp + outputbuf->size - output.fade_start) / BYTES_PER_FRAME;

// frames_t dur_f = output.fade_end >= output.fade_start ? (output.fade_end - output.fade_start) / BYTES_PER_FRAME :

// (output.fade_end + outputbuf->size - output.fade_start) / BYTES_PER_FRAME;

///* if (cur_f >= dur_f) {

// if (output.fade_mode == FADE_INOUT && output.fade_dir == FADE_DOWN) {

// LOG_INFO("fade down complete, starting fade up");

// output.fade_dir = FADE_UP;

// output.fade_start = outputbuf->readp;

// output.fade_end = outputbuf->readp + dur_f * BYTES_PER_FRAME;

// if (output.fade_end >= outputbuf->wrap) {

// output.fade_end -= outputbuf->size;

// }

// cur_f = 0;

// } else if (output.fade_mode == FADE_CROSSFADE) {

// LOG_INFO("crossfade complete");

// if (_buf_used(outputbuf) >= dur_f * BYTES_PER_FRAME) {

// _buf_inc_readp(outputbuf, dur_f * BYTES_PER_FRAME);

// LOG_INFO("skipped crossfaded start");

// } else {

// LOG_WARN("unable to skip crossfaded start");

// }

// output.fade = FADE_INACTIVE;

// output.current_replay_gain = output.next_replay_gain;

// } else {

// LOG_INFO("fade complete");

// output.fade = FADE_INACTIVE;

// }

// }*/

// // if fade in progress set fade gain, ensure cont_frames reduced so we get to end of fade at start of chunk

// //if (output.fade) {

// // if (output.fade_end > outputbuf->readp) {

// // cont_frames = min(cont_frames, (output.fade_end - outputbuf->readp) / BYTES_PER_FRAME);

// // }

// // //if (output.fade_dir == FADE_UP || output.fade_dir == FADE_DOWN) {

// // // // fade in, in-out, out handled via altering standard gain

// // // s32_t fade_gain;

// // // if (output.fade_dir == FADE_DOWN) {

// // // cur_f = dur_f - cur_f;

// // // }

// // // fade_gain = to_gain((float)cur_f / (float)dur_f);

// // // gainL = gain(gainL, fade_gain);

// // // gainR = gain(gainR, fade_gain);

// // //}

// // //if (output.fade_dir == FADE_CROSS) {

// // // // cross fade requires special treatment - performed later based on these values

// // // // support different replay gain for old and new track by retaining old value until crossfade completes

// // ///* if (_buf_used(outputbuf) / BYTES_PER_FRAME > dur_f + size) {

// // // cross_gain_in = to_gain((float)cur_f / (float)dur_f);

// // // cross_gain_out = FIXED_ONE - cross_gain_in;

// // // if (output.current_replay_gain) {

// // // cross_gain_out = gain(cross_gain_out, output.current_replay_gain);

// // // }

// // // if (output.next_replay_gain) {

// // // cross_gain_in = gain(cross_gain_in, output.next_replay_gain);

// // // }

// // // gainL = output.gainL;

// // // gainR = output.gainR;

// // // cross_ptr = (s32_t *)(output.fade_end + cur_f * BYTES_PER_FRAME);

// // // } else {

// // // LOG_INFO("unable to continue crossfade - too few samples");

// // // output.fade = FADE_INACTIVE;

// // // }*/

// // //}

// //}

// }

//}

 

out_frames = !silence ? min(size, cont_frames) : size;

 

 

//wrote = output.write_cb(out_frames, silence, gainL, gainR, cross_gain_in, cross_gain_out, &cross_ptr);

wrote = output.write_cb(out_frames, silence, NULL, NULL, NULL, NULL, NULL);

 

 

 

 

 

if (wrote <= 0) {

frames -= size;

break;

} else {

out_frames = (frames_t)wrote;

}

 

 

size -= out_frames;

 

 

//_vis_export(outputbuf, &output, out_frames, silence);

 

 

if (!silence) {

_buf_inc_readp(outputbuf, out_frames * BYTES_PER_FRAME);

//output.frames_played += out_frames;

}

}

 

//LOG_SDEBUG("wrote %u frames", frames);

 

 

return frames;

 

and

 

static int _write_frames(frames_t out_frames, bool silence, s32_t gainL, s32_t gainR,

s32_t cross_gain_in, s32_t cross_gain_out, s32_t **cross_ptr) {

 

if (!silence) {

 

//if (output.fade == FADE_ACTIVE && output.fade_dir == FADE_CROSS && *cross_ptr) {

//_apply_cross(outputbuf, out_frames, cross_gain_in, cross_gain_out, cross_ptr);

//}

 

//if (gainL != FIXED_ONE || gainR!= FIXED_ONE) {

//_apply_gain(outputbuf, out_frames, gainL, gainR);

//}

 

 

//IF_DSD(

//if (output.dop) {

//update_dop_marker((u32_t *) outputbuf->readp, out_frames);

//}

//)

 

//VirtualProtect(outputbuf->readp, out_frames * BYTES_PER_FRAME, 0x00, &oldProtection);

 

 

//memcpy(optr, outputbuf->readp, out_frames * BYTES_PER_FRAME);

//__movsb(optr, outputbuf->readp, out_frames * BYTES_PER_FRAME);

__movsq((PDWORD64) optr, (DWORD64*) outputbuf->readp, out_frames * BYTES_PER_FRAME/8);

//__movsd((PDWORD) optr, (DWORD*) outputbuf->readp, out_frames * BYTES_PER_FRAME / 4);

//__movsw((PWORD) optr, (WORD*) outputbuf->readp, out_frames * BYTES_PER_FRAME / 2);

//VirtualProtect(outputbuf->readp, out_frames * BYTES_PER_FRAME, 0x04, &oldProtection);

 

 

 

 

 

 

} else {

 

 

//u8_t *buf = silencebuf;

 

 

// //IF_DSD(

// //if (output.dop) {

// //buf = silencebuf_dop;

// //update_dop_marker((u32_t *) buf, out_frames);

// //}

// //)

 

 

// memcpy(optr, buf, out_frames * BYTES_PER_FRAME);

__movsq((PDWORD64) optr, (DWORD64*) silencebuf, out_frames );

//

}

 

optr += out_frames * BYTES_PER_FRAME;

 

 

return (int)out_frames;

}

[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

[cvrle59]

I am "JLp V30/31 handicapped". I doesn't work on my system at all...sorry 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

[sima66]

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.

 

Perfect, then you can use v30 and still have both.........quality and functionality! ;-)

[sbgk]

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

 

and guess how the volume is controlled - via gain.

[sbgk]

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

 

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

 

I've only really scratched the surface with jlp . I am hearing better detail and a smoother sound, MQn I always thought was a bit choppy which I put down to wasapi.

 

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.

[sbgk]

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

 

you do have to wait a few seconds for the music to start with these versions, don't know if that's the issue.

[cvrle59]

you do have to wait a few seconds for the music to start with these versions, don't know if that's the issue.

Even 5 min doesn't help. I am afraid that there is more to it (system specifics), sorry. I tried any possible scenario with different buffers sizes too.

[sbgk]

Even 5 min doesn't help. I am afraid that there is more to it (system specifics), sorry. I tried any possible scenario with different buffers sizes too.

 

have you tried a complete restart of everything ?

[cvrle59]

Yes, I did, a few times, they are both running as services.

[John Dot]

Yes, I did, a few times, they are both running as services.

 

Have you tried different -a values like 25, 250, 500? It worked for me.

[cvrle59]

Have you tried different -a values like 25, 250, 500? It worked for me.

I changed 1, 10 and 23. I will try higher tonight, as you mentioned.

[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!

[erin]

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

 

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.

[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!

[lebav]

Hi everyone,

 

I am new on the forum and new with streaming audio. I find this thread very interesting and I have 3 questions. 1) are the products on this thread compatible with Windows 7 Pro (SP1) or do I need Windows 8.1 2) Same question for MQN 3) Am I correct to assume the these products will send the music to the UBS port of my laptop. I have Jriver installed on my laptop and it works fine with my DAC via a USB connection.

 

Many thanks for your assistance

Regards,

Michel