The official Lessloss Laminar Streamer SD card player thread

[wappinghigh]

Let's start an official thread, watching for this player's release and upgrades

 

Because this little player is about to shake the CA world and turn it on it's head:

 

Laminar Streamer SD player : High end SD player | Solid state memory player | Computer audio player

 

It's going to also sit nicely in houses with an Invicta DAC and/or portable HiREz players that also play off SD cards (like the Hifiman)

 

...for obvious reasons..

 

Post away your thoughts or any links you can find on this player!

[Audio_ELF]

Because this little player is about to shake the CA world and turn it on it's head

Quite a bold statement for something that (as far as I can tell) is currently vapour ware... Oh and surely it's only an unofficial thread unless either you are (a) Chris or have his approval to make it official or (b) you're connected with Lessloss in which case you definitely need Chris' approval to post about it.

 

The "Small screen displays folder names, file names, sampling rates, absolute phase polarity, playback mode, and time." description immediately turns me off and thinks it will never turn the CA world on it's head.

 

Anyway thats my thoughts...

 

Eloise

[wappinghigh]

Ok. So it's Unofficial then. And no. It's not vapour ware. Very much alive and no I'm not connected.

[4est]

I didn't see an approximate price. Anyone know it?

[Audio_ELF]

Ok. So it's Unofficial then. And no. It's not vapour ware. Very much alive and no I'm not connected.

Oh sorry... Where can I demo one? All I could see were design sketches and a list of spec.

[beaur]

Hopefully they will bring a working model to the NYC show in April.

 

Basically this looks like a CD player that uses SD cards. No external control i.e. ipad or tablet.

 

As they don't exist in the real world yet we can only comment on features not sonics. The control issue will be a big one for me. It appears that each SD card will be treated like a CD so you will be playing lists downloaded from your computer to the card. Do you have to play tracks in the order they are downloaded? or is there some way to manipulate the order? Assuming you have a 256GB (edit: just noticed that the largest capacity they mention is 32GB) card thats a big playlist to remember if you cant see the card contents via some type of remote.

 

Assuming all their tech makes this sound great, give me a way to control this and visually see what's in the player and I would take a look at it.

 

As for pricing, none of their other stuff is inexpensive but it's not break the bank either. Are they going to price this like an Aurender or a Squeezebox, only time will tell.

[Kal Rubinson]

Basically this looks like a CD player that uses SD cards.

Like the SB Touch.

[Audio_ELF]

Like the SB Touch.

Strange comparison. I don't think many people use the SB Touch with SD cards; most use it as a streamer.

[wappinghigh]

Hopefully they will bring a working model to the NYC show in April.

 

Basically this looks like a CD player that uses SD cards. No external control i.e. ipad or tablet.

 

As they don't exist in the real world yet we can only comment on features not sonics. The control issue will be a big one for me. It appears that each SD card will be treated like a CD so you will be playing lists downloaded from your computer to the card. Do you have to play tracks in the order they are downloaded? or is there some way to manipulate the order? Assuming you have a 256GB (edit: just noticed that the largest capacity they mention is 32GB) card thats a big playlist to remember if you cant see the card contents via some type of remote.

 

Assuming all their tech makes this sound great, give me a way to control this and visually see what's in the player and I would take a look at it.

 

As for pricing, none of their other stuff is inexpensive but it's not break the bank either. Are they going to price this like an Aurender or a Squeezebox, only time will tell.

 

Very good points. I agree 100%

 

I raised the SDHC limitation with the designer only yesterday and it is still unclear and untested if this *is* actually a limitation. In other words it may well be a software limitation to SDHC or in fact no limitation at all. In other words SDXC cards may well work. We may only find out when the player is released. If you think about this, that was the state of play with a couple of these SD card players when they were first released. The Invicta DAC being one of them.

 

I completely concur re the comments about control though. I have no idea what the designers propose on this front. Pity this isn't some sort of kick starter where we could add this sort of valuable input

[wappinghigh]

^ I believe they will be showing one at the April NYC show. So if any one sees and hears it, could they please post

[dpaws]

I very much doubt there will be a working model as yet, not even a 3D printed mock-up by all accounts. I've had some private discussions with the designer and the project is very much "vapour ware" at present - and I can't see any possibility that reality will reach this project for quite some time.

 

Although I am a fan of Lessloss and their left of field perspectives, I do have one issue with this player - how are you going to preserve this data stream so that it reaches the clock of your D/A without incurring timing errors? The SPDIF interface has it's issues, as does the i2s output stream. Any notion of re-clocking within the D/A defeats the object of the single clock purity from OS down to data stream.... Maybe I've missed something?

[ted_b]

Wap,

I am all for innovation and discovery, for left field thinking and out of the box concepts. A dedicated music server OS; cool! But this streamer (seems a weird term for this, it does not stream in the accepted sense) has to sound like 5X better than any other music server to put up with the amazing amount of inconvenience:

* library limited to 32GB at a time? Really?

* browsing via front panel one or two line scrolling (and how does it have this metadata if it uses wav files); no remote or remote display capability? How do I browse at all?

* SPDIF interface, which means some inherent jitter, right, which is exactly what they are trying to eliminate with the remaining ultra-minimalist architecture (serious question; I am so deep into USB that I haven't played around with SPDIF in awhile and thought it still presents jitter hurdles)...oops didn't read dpaws post...I agree with it!

 

Lessloss has been at the forefront of some good ideas and good products; I am willing to listen...we MUST be missing something.

[dpaws]

Well, the photos are in.. Chester Group New York Audio Show 2013 Report just past halfway down...

 

Huge disappointment - it's another cardboard cutout picture!! I can only assume with an open PCB hiding behind the disguise. (What a joke!!) Not a lot to show for a whole year of development - at this rate the SD card will be obsolete by the time the player hits the marketplace.

 

More worrying for Lessloss is that not one of the bloggers has even mentioned the sound quality... there is still time though

[beaur]

Most disappointing room at the show as I at least wanted to see the streamer. Once I saw the cardboard I lost even an interest in trying to peek.

 

Sound wasn't too bad when I was in but the transitions between songs was a little jarring. They might have had it on random play and transitioning between several pieces was a little odd sounding. Don't know if that was an effect of gapless playback with random songs or just something in the software.

 

Maybe next year!!

[dpaws]

Another disappointed fan here The LessLoss Laminar Streamer | AudioStream - and all for under $15k?

 

Errr, you can officially count me out!!! What planet? What a let down!

[monteverdi]

I like the idea of a digital player who's sole purpose is to play music: a simple OS with a good file managing systems, excellent clocks and one output option your systems likes best. Storage on Sd is great or SSD or? Navigation should be more than back forward and stop! (but no shuffle or party mode)

Seeing the design ideas on the LessLoss website and its name looks that a good idea turned into audiophile fluff. 15K for some "new" idea which is already successfully implemented by several companies in a big fancy=tasteless box is a sign of the present high end audio, a niche market for obsessive compulsive which happen to have a lot of disposable funds.

I would like a small device which can just plug in directly in my fancy DAC.

[dpaws]

Thinking aloud, and other thoughts very welcome - surely this concept would only have the potential to achieve a new level of performance if the master PC clock crystal was the same one that controlled the clock in the DAC section, effectively having a master clock scenario... but the clock would have to be exceptional and, if digital only, it would require a DAC with a word clock input....

[Louis Motek - LessLoss]

Thinking aloud, and other thoughts very welcome - surely this concept would only have the potential to achieve a new level of performance if the master PC clock crystal was the same one that controlled the clock in the DAC section, effectively having a master clock scenario... but the clock would have to be exceptional and, if digital only, it would require a DAC with a word clock input....

 

This last question is one which has come up before (even to ourselves!) and will inevitably come up again, so I think a differentiated response is in order.

 

Yes, one would think that in all cases, a proper Master/Slave relationship with the DAC Master Clock synchronously re-clocking the digital stream coming from a synchronously slaved digital source device would always create the best conditions for the lowest possible Jitter at the moment and place of D/A conversion. And, for many years, this is exactly what we at LessLoss offered. Today we see this in a little bit different way, which requires a little bit more differentiated thought.

 

Let's start with a synchronously slaved DAC scenario, then we'll go to asynchronous re-clocking (two clocks), then we'll get to synchronous re-clocking (one clock), and then we'll go back to the synchronously slaved DAC scenario.

 

Synchronously slaved DAC scenario

 

[ATTACH=CONFIG]5346[/ATTACH]

 

In this scenario, any clock Jitter which is present at the place and time of source clocking will contribute to distortion of the analogue signal after D to A conversion. In other words, you get what you get; it's that simple. If you have a bad clock, you will have bad sound. If you upgrade the clock, you will have that much better sound. If you have a better shield on your digital cable, you will have better sound as well. Everything that happens at the source has direct relation to sound quality after D to A conversion. For better or for worse.

 

There's another way to do it, though, called:

Asynchronous re-clocking

[ATTACH=CONFIG]5347[/ATTACH]

 

In this two-clock scenario, the separate, second clock which runs the DAC process disregards the original clock which came with the data stream. This cutting off of the original clock timing and re-clocking it with a second, independent clock source is called asynchronous because it is not a process which is locked in time. No two clocks can ever run at the same speed exactly. Slippage between them occurs. This slippage, however, causes very little Jitter. Much less, in fact, than the "cheap" clock and perhaps cheap digital cable caused which was originally used at the source. Hence, the solution results in a huge upgrade in sound quality over the synchronously slaved DAC scenario above.

 

There is, however, a threshold of performance which the 'source clock' must be worse than in order for the asynchronous re-clocking scheme above to perform its magic. If the 'source clock' and digtial cable technologies were in fact better than the 'other clock' above, and if the 'other clock' is performing worse than the 'source clock' by the time the 'source clock signal' arrives at the DAC, then we have a downgrade in quality and the asynchronous re-clocking DAC is now performing more harm than if that second clock were turned off.

 

Now we come to the crux of the matter. We come to the part that (it seems) only very few people are cognizant of. And this pertains to the "holy grail" of:

 

Synchronous re-clocking

[ATTACH=CONFIG]5348[/ATTACH]

 

Now we have only one clock, so we have no more 'slippage' between two clocks running at different rates. So far so good. We also disregard the clock signal which went all the way around from clock to source and back again, this time paired with data from the source, all the way back to the DAC chip. We disregard it because it is known to now contain more Jitter than the clock source it originated from, which is right here and available anyway. So we disregard the 'long travelled' clock and we pair the data stream with the original clock it was born from. Voila! Perfect synchronization and perfect Jitter reduction! Right?

 

Almost. As it turns out, this synchronous re-clocking can be outdone by the more simple system of a synchronously slaved DAC scenario above, provided HF reflections are attenuated amply and provided the original clock signal used in both cases be of ample high quality.

 

What's striking is the following. There is a threshold of Jitter content which much be present in order for the asynchronous re-clocking scenario above to improve upon it. If this threshold of Jitter content is not met, the solution actually degrades the sound quality by introducing more jitter than there was to begin with.

 

In the same way, in the synchronous re-clocking scenario, where there's only one clock, if the clock signal travels full circle and does not get corrupted, and is then discarded and re-clocked, we are actually loosing quality we would otherwise have gained had we simply disengaged the re-clocking function altogether. But in this case, which, granted, is indeed a special case, we should have simply placed the high performance clock in the source device to begin with, to save us that extra first leg of distance altogether! It is ironic but in a way beautiful that when we follow all of these steps full circle, always improving upon each and every step, we are led back to the very beginning where we started from, this time at a higher level of performance due to the use of a very high quality clock source and because we have properly dealt with high frequency reflection attenuation and minute acoustical vibration issues. Once we are back at square one, we realize just how true the saying is that "simpler is always better".

 

In other words, the moral of the story is "It is laudable to fix mistakes that happened, but if it ain't broke, don't fix it!"

 

Enter computer audio clocking

 

 

This is the way computer clocking works before the audio is streamed out to a DAC. Again, we have the issue that the CPU runs at a different speed as the source which streams the data. Buffering and synchronization issues must be overcome through that inevitable 'slippage' between multiple clocks and this always causes Jitter.

 

And so our solution is:

 

 

It required of us to engineer our own operating system from ground up, because no pre-written modules existed which did what we needed the OS to do in a direct drive setting without 'clock slippage'.

[Wavelength]

Louis,

 

Let me clarify a few things from someone who has worked on chips for 30 years.

 

All modern day dacs with exception to ladder units, only rely on the Master Clock as the reference point for all jitter related errors. Therefore locating the Master Clock (or clocks) as close to the dac chip as possible will result in the lowest jitter. Locating the clock at the computer would result in the worst possible jitter.

 

Gross jitter related errors can happen at the I2S level if large amount of jitter occur. So if you feedback the Master Clock located at the dac chip to the component creating the I2S feed, then you will result in the lowest jitter.

 

Of course reclocking with that same Master Clock at the dac chip will result in lowering the variation caused by circuit board trace lengths and other variables between the Audio Receiver and the dac chip.

 

Putting the clock at the computer is actually the worst place to do this. I have written tons of software since 1981 when I released some of my first code in CPM, then DOS, Windows, Mac, UNIX, Linux and other platforms. Creating the system you are talking about is a waste of time. You need to get the clock back in the DAC and then use asynchronous flow control to get the data to the DAC in a way so that the data does not underrun or overrrun.

 

Also you want to isolate completely the link between the noisey CPU and the DAC chip so there will not be any of that noise present in the DAC and Analog sections.

 

I would take a better look at your system as it is not a good solution.

 

Thanks,

Gordon

This last question is one which has come up before (even to ourselves!) and will inevitably come up again, so I think a differentiated response is in order.

 

Yes, one would think that in all cases, a proper Master/Slave relationship with the DAC Master Clock synchronously re-clocking the digital stream coming from a synchronously slaved digital source device would always create the best conditions for the lowest possible Jitter at the moment and place of D/A conversion. And, for many years, this is exactly what we at LessLoss offered. Today we see this in a little bit different way, which requires a little bit more differentiated thought.

 

Let's start with a synchronously slaved DAC scenario, then we'll go to asynchronous re-clocking (two clocks), then we'll get to synchronous re-clocking (one clock), and then we'll go back to the synchronously slaved DAC scenario.

 

Synchronously slaved DAC scenario

 

[ATTACH=CONFIG]5346[/ATTACH]

 

In this scenario, any clock Jitter which is present at the place and time of source clocking will contribute to distortion of the analogue signal after D to A conversion. In other words, you get what you get; it's that simple. If you have a bad clock, you will have bad sound. If you upgrade the clock, you will have that much better sound. If you have a better shield on your digital cable, you will have better sound as well. Everything that happens at the source has direct relation to sound quality after D to A conversion. For better or for worse.

 

There's another way to do it, though, called:

Asynchronous re-clocking

[ATTACH=CONFIG]5347[/ATTACH]

 

In this two-clock scenario, the separate, second clock which runs the DAC process disregards the original clock which came with the data stream. This cutting off of the original clock timing and re-clocking it with a second, independent clock source is called asynchronous because it is not a process which is locked in time. No two clocks can ever run at the same speed exactly. Slippage between them occurs. This slippage, however, causes very little Jitter. Much less, in fact, than the "cheap" clock and perhaps cheap digital cable caused which was originally used at the source. Hence, the solution results in a huge upgrade in sound quality over the synchronously slaved DAC scenario above.

 

There is, however, a threshold of performance which the 'source clock' must be worse than in order for the asynchronous re-clocking scheme above to perform its magic. If the 'source clock' and digtial cable technologies were in fact better than the 'other clock' above, and if the 'other clock' is performing worse than the 'source clock' by the time the 'source clock signal' arrives at the DAC, then we have a downgrade in quality and the asynchronous re-clocking DAC is now performing more harm than if that second clock were turned off.

 

Now we come to the crux of the matter. We come to the part that (it seems) only very few people are cognizant of. And this pertains to the "holy grail" of:

 

Synchronous re-clocking

[ATTACH=CONFIG]5348[/ATTACH]

 

Now we have only one clock, so we have no more 'slippage' between two clocks running at different rates. So far so good. We also disregard the clock signal which went all the way around from clock to source and back again, this time paired with data from the source, all the way back to the DAC chip. We disregard it because it is known to now contain more Jitter than the clock source it originated from, which is right here and available anyway. So we disregard the 'long travelled' clock and we pair the data stream with the original clock it was born from. Voila! Perfect synchronization and perfect Jitter reduction! Right?

 

Almost. As it turns out, this synchronous re-clocking can be outdone by the more simple system of a synchronously slaved DAC scenario above, provided HF reflections are attenuated amply and provided the original clock signal used in both cases be of ample high quality.

 

What's striking is the following. There is a threshold of Jitter content which much be present in order for the asynchronous re-clocking scenario above to improve upon it. If this threshold of Jitter content is not met, the solution actually degrades the sound quality by introducing more jitter than there was to begin with.

 

In the same way, in the synchronous re-clocking scenario, where there's only one clock, if the clock signal travels full circle and does not get corrupted, and is then discarded and re-clocked, we are actually loosing quality we would otherwise have gained had we simply disengaged the re-clocking function altogether. But in this case, which, granted, is indeed a special case, we should have simply placed the high performance clock in the source device to begin with, to save us that extra first leg of distance altogether! It is ironic but in a way beautiful that when we follow all of these steps full circle, always improving upon each and every step, we are led back to the very beginning where we started from, this time at a higher level of performance due to the use of a very high quality clock source and because we have properly dealt with high frequency reflection attenuation and minute acoustical vibration issues. Once we are back at square one, we realize just how true the saying is that "simpler is always better".

 

In other words, the moral of the story is "It is laudable to fix mistakes that happened, but if it ain't broke, don't fix it!"

 

Enter computer audio clocking

 

[ATTACH=CONFIG]5349[/ATTACH]

 

This is the way computer clocking works before the audio is streamed out to a DAC. Again, we have the issue that the CPU runs at a different speed as the source which streams the data. Buffering and synchronization issues must be overcome through that inevitable 'slippage' between multiple clocks and this always causes Jitter.

 

And so our solution is:

 

[ATTACH=CONFIG]5350[/ATTACH]

 

It required of us to engineer our own operating system from ground up, because no pre-written modules existed which did what we needed the OS to do in a direct drive setting without 'clock slippage'.

[dpaws]

Wow - well first of all - thanks guys for debating in public, it really helps the rest of us mere mortals understand what keeps you gurus awake all night!!

 

I assume from the above that the single master clock idea is a good one (well, not a bad idea at least - and maybe a little dated...), but it has to be based at the DAC rather than on the PC board?

 

Just thinking it through.. before playback the next track would have to be assessed for its properties (sample rate) with this information then fed to the master clock inside the DAC. If a clock frequency changeover is required then the system would have to remember the track/playlist, reboot, reconfirm the sample rate match up before playing?

 

For the data stream I suppose an optical isolation and a FIFO buffer, I recall something about a digital wheel but I can't find the link!?! All this of course relies on a live stream of data, where as the use of memory playback from traditional PC based systems would appear to be favorable - would you simply increase the size of that buffer to accommodate the playlist contents or am I getting tangential and confuffled?

 

It all sounds rather complicated - but acoustically is it really worth the trouble?

[CoolHand]

Timing is everything....small clock syndrome can really give you the jitters ;-)

 

 

[Geardaddy]

Timing is everything....small clock syndrome can really give you the jitters ;-)

 

 

[ATTACH=CONFIG]5484[/ATTACH]

 

Coolhand, that is brilliant.....

[Ned Kelly]

Had to dig this up - over 2 years since the OP made the prediction that the Laminar Streamer was 'about to turn the CA world on it's head', this remains vaporware. After the farcical 'we cant show you whats behind the curtain' show debut and the 'less than 15k' guesstimate, LessLoss seem to have decided this wasnt actually their finest hour.

 

By contrast, after starting a naming contest for a fictional portable headphone amp at around the same time, Cavalli Audio actually released not one but two portable amps somewhere in the 500-700 USD range at CANJAM 2015 last weekend in SoCal. While I guess many here will be thinking 'Wow - a couple of small amps vs a product that aimed to revolutionise digital transports ..', it remains the difference between talking the talk and walking the walk and those who heard the amps came away impressed which seems to be more than anyone could say after the Streamer's debut. The kicker - at least IMO - is that Alex Cavalli also came from a software background and would be acutely aware of the risks of trying to sell vaporware : you can write all the white papers and web pages you want, hire a red hot graphic designer and print 3D prototypes but until you have something that makes music, it might as well be a flying pig.

[Kal Rubinson]

Strange comparison. I don't think many people use the SB Touch with SD cards; most use it as a streamer.

 

Intentional. The device has less appeal to me (on paper) than the SBT.

[Cebolla]

Strange comparison. I don't think many people use the SB Touch with SD cards; most use it as a streamer.

Intentional. The device has less appeal to me (on paper) than the SBT.

Wow, that's over 2 years to reply to a post! I'm surprised you can still remember your original train of thought