PDA

View Full Version : Community Funded Squeezebox Replacement - Would you be interested?



Pages : [1] 2 3 4 5 6

dustinsterk
2013-01-18, 20:06
Hello,
With all of the recent developments with Logitech and the end of the squeezebox line I feel as this community has been unfairly ignored. This community of audiophiles, software developers, engineers, DIY builders, and lovers of music is very strong. Many of you have been users of the squeezebox products since slimdevices. With Triode's EDO and squeezelite developments, the community behind Vortexbox (Agillis), Erland, Pippin, and all other developers/groups and enthusiasts that dedicate all of their free time to this product, I have been thinking we should start a crowd (community) funded product similar to the Olive One to develop and build a squeezebox replacement.

Sure, the Pi, Pogoplug and other hardware have bits and pieces that we can hack into a working player but it is NOT what we really want or need. I would say as a community, this forum has more experience and insight into what the next product should look like than any other up and coming product (Olive One). We not only have ideas, but users that are willing to invest time and effort for no other reason then to better an already wonderful product.

So my question to everyone is simple......if there was a community funded project, would you invest your time? Would you invest monetarily? We all have different strengths and as a community I think we could really design one hell of a product.

Maybe I am wrong, but I truly do feel other users want to see this continue. If you do, please post what you would be willing to contribute. Personally I would be willing to help in anyway possible. I am an entrepreneur and software developer by day and DIY audiophile lover by night.

--Dustin

JJZolx
2013-01-18, 20:22
I just can't imagine anyone willing to volunteer that much time and energy into building such a thing without realizing some monetary compensation. You're talking about something _way_ above and beyond the (albeit very impressive) software efforts put forth by third party software developers. System design, circuit board layout, prototyping... wow. I don't see anyone doing that for grins. And it's not really something that 100 people can pitch in on, even if they all had the skills. There probably aren't more than one or two people remaining with an interest in Squeezebox who actually have the ability to do the system and circuit board design necessary to create a real replacement.

dustinsterk
2013-01-18, 20:46
I just can't imagine anyone willing to volunteer that much time and energy into building such a thing without realizing some monetary compensation. You're talking about something _way_ above and beyond the (albeit very impressive) software efforts put forth by third party software developers. System design, circuit board layout, prototyping... wow. I don't see anyone doing that for grins. And it's not really something that 100 people can pitch in on, even if they all had the skills. There probably aren't more than one or two people remaining with an interest in Squeezebox who actually have the ability to do the system and circuit board design necessary to create a real replacement.

I do agree that without financial compensation some may say whats the point. I also agree that there are a limited few that have the background to tackle such a task. But when I look at all the talent here and other DIY sites (head-fi, diytube, diyaudio, diyforums, etc) I know we could find the resources to put something together.

I guess a better question would be does anyone have interest in such a venture?

erland
2013-01-18, 22:35
For any developers or hardware engineers with proven previous experience in these areas who are really serious/interested about doing something like this, I would also encourage you to join the private developers mailing list which we setup earlier:
http://forums.slimdevices.com/showthread.php?96463-Announce-Private-mailng-list-forum-for-developer-discussions
Reason simply being that some things like this is going be easier to discuss in a smaller group than in a public forum.

The mailing list will be limited to those who in some way or another have shown what they can accomplish related to Squeezebox, typically this means people who have developed plugins/applets or third party hardware solutions. At this stage it's not for people who can just help testing or provide feedback.

There is currently no community effort going on in this mailing list, I'm mainly just trying to get people who can do something and is willing to do it to join it so we have a more private place to discuss it in more detail.

erland
2013-01-18, 23:09
I just can't imagine anyone willing to volunteer that much time and energy into building such a thing without realizing some monetary compensation. You're talking about something _way_ above and beyond the (albeit very impressive) software efforts put forth by third party software developers. System design, circuit board layout, prototyping... wow. I don't see anyone doing that for grins. And it's not really something that 100 people can pitch in on, even if they all had the skills. There probably aren't more than one or two people remaining with an interest in Squeezebox who actually have the ability to do the system and circuit board design necessary to create a real replacement.

For a purely software project done on the spare time it would have to be at least 3-4 persons who all have the architecture/design skills and not just simple coding skills. It's one thing to provide a patch or edit a source code file, it's a completely different thing to architect/design a new system from a blank sheet of paper.
For a hardware project I imagine that you would have to add a few additional people to handle that part, one would be a minimum but for long time survival that part would probably also require 2-4 people if it's done on the spare time.
On top of this you would have to have some testers but those are easy to find around here, the challenge is just to make them to structured testing and not just random testing all over the place.

It can't be a lot more people than this because then it gets too crowded and the people who know what to do end up spending the time trying to explain to other people what to do and how to do it.
It can't be less people if it's done as a spare time project because then the project will halt when the family situation changes for one of the persons and he/she no longer can spend time on the project, I have seen exactly this issue in the SMD project where we were 3 core contributors and that was enough as long as we all had enough spare time, when one disappeared everything more or less halted. If it's a full time project you can have less people but not in a spare time project which people can maximum spend 10 hours/week on.

I also believe it needs to be a company behind it for it to work on longer terms, doesn't have to be an existing company, can be a new one, but there needs to be a business aspect else it will never survive on longer terms. Most people enjoy to contribute for free a few years but eventually (with a few exceptions) most are eventually going to want some kind of continuous economical compensation if they need to offer all their spare time for the project. Some are even only going to want to continue working on it long term if they can have it has their day job.

I'm fairly sure there are enough people with the right skills in this community to create something new. There isn't enough remaining if you purely look at those who have done plugins/applets and third party hardware packaging, but I've realized that there are a lot of people lurking around here who have a lot of experience from their day jobs even if they have never done any spare time work related to Squeezebox to show their abilities. The question is just how to attract them to do something on their spare time and if they have the ability/willingness to work together as a team.

The hardest people to find around here seems to be people with non technical skills, like graphical design and drawing, and that's also something that's definitely needed if you want to accomplish a consumer product and not just a DIY project.

All this makes me think that it's not unrealistic at all that something new is going to be released from someone in this community, the question is more about when it will happen, who will be part of it and if it will be released through a company or community effort. I also know there are a companies doing products in this market segment who wants to take a part of the cake Logitech has left behind. So overall, I think the next 6-12 months might be pretty interested in the music streaming market, I just hope that Sonos doesn't get too strong so it will be too hard for someone else to establish a new platform.

Mnyb
2013-01-19, 01:55
You may need some CAD skills prototyping and design skills for a product .

Prototype can lurk in an over the counter generic box or a shoebox (shoebox lid can work as temporary circiut board to :) just punch holes for component legs ) , but to actually sell it to more than 100 people it has to be cosmetically acceptable . Imo the SB3 is a classic it have never looked better , transporter is ok so but it align a little bit to audiophile design aesthetic (if something looks like a steam powered difference engine with computer control it sells in those quarters ) .SB2 looks like a modem . Touch is ok as it resembles SB3 but it could improve a bit .

Prototype boards etched at home is one thing a multilayer smd pcb thats possible to manufascture probably demands skills and software i haven’t heard of :) but sure there are such people here , there sure is some kind of file you send to chines plant and order a test batch of 10000 boards ,just joking but there probably is challenge to have some scale of economics in small series .

And tight control of the design spec who should be detailed and in control , the audiophiles would discuss dac chips until the end of days :)

But on the positive side it could have some unique design specifics , for example fpga based filters the forum has such a designer (hello John ) with uncomercial tweaks like headromm for intersample overs (no specman ship ) .

It could also build heavilly on squeezeplay fitting it to more memory and cpu and have some if its bugs fixed and added flexibility .

I foresee that a debate would be screen or no screen . I'm for no screen in the first "community squeezebox" as it removes all design headaches of an UI and removes components that probably are cheap and common in large scale products like phones but I doubt the prices are any good if you want 200pcs for a small null series .

JJZolx
2013-01-19, 09:51
If you're an audiophile looking for highest sound quality, an external async USB DAC will give you better fidelity than an internal one in anything other than a very expensive Squeezebox replacement. So, without a screen and a touch and/or IR user interface, what real need is there for a replacement, when just about any computer with a USB port can today function as Squeezebox?

And if you're not an audiophile, a computer with onboard sound or sound card will suffice. If you accept that a device without user I/O is sufficient, then there's little need for a true Squeezebox. Except perhaps for better synching of zone players in a multi-zone system. However, this also requires that such devices be relatively inexpensive, which will be an almost impossible goal for a community project that won't sell more than a couple hundred units.

I've said in the past that an established audio company might be a good candidate for producing a Squeezebox capable player. Probably the biggest obstacle to that, however, is the current state of the server software and the astronomical costs of both supporting it and of maintaining it.

Bottom line: It's just not going to happen, no matter how you slice it.

Triode
2013-01-19, 10:34
I'm not sure whether we can turn this into a community product, but my personal view is that an effective Squeezebox replacement for the community can be made from a small existing arm based device + an external usb dac. This means all the audio engineering can be part of the dac and you can spend from $5 to $5000 based on your preference....

The device itself is probably based on something already available such as an android stick, raspberry pi or other such device - perhaps we need to settle on one or a small number of recommended devices and package for them. The one thing that most devices have now with hdmi, so a user interface using hdmi + control over that is probably required/sensible. This is not a mass market consumer product, but it gets us to a very viable solution for community enthusiasts... (and focusses much of the effort on software and packaging rather than hardware design and the necessary volumes this brings)

Squeezelite part of my steps in this direction. I'd like to look at UI solutions, perhaps integration with XBMC or alternative user interfaces hdmi - any takers?

erland
2013-01-19, 12:07
I've said in the past that an established audio company might be a good candidate for producing a Squeezebox capable player. Probably the biggest obstacle to that, however, is the current state of the server software and the astronomical costs of both supporting it and of maintaining it.

Is the maintenance cost really that bad ?
How many full time developers have Logitech had during the last 2-3 years working with maintenance that really had to be done ?
To me it kind of feels like most of the work during last years have either been various kind of refactoring and Revue related stuff which was doomed before it started. Looking back two years in time, it feels like there have been less than one full time developer working on the server in average. There were obviously a bit more during development of the Touch, but it's pretty normal that more resources is needed when you develop a new product which requires big changes.

SBS 7.5.3 is about 2 years old, what "must have" functionality has been done in the server after that ?
My feeling is the cost isn't really about things that had to be done, it's more related to bad management and prioritization.
Are you sure the UPnP server software of your choice required less maintenance and support during the last two years ?

Support is another matter, but I've got the feeling that this community has handled a lot of support issues and only a few people have actually taken the time to call the official Logitech support even though we have tried to push more people to do it during the last years.

However, generally I agree that the server software probably don't have a future outside Logitech, but Logitech could still maintain the server and license the ability for third parties to produce players. This will of course not happen because Logitech is really a hardware company and not a software company, so it probably never really made sense to them to let third parties produce the hardware.

erland
2013-01-19, 12:39
Bottom line: It's just not going to happen, no matter how you slice it.

Depends on what you mean with Squeezebox replacement.

1. DIY products is/will happen, we are already seeing this now, but for these we are likely taking about very small volumes, maybe a few hundred devices or something similar. Someone might try to package one pre-installed, but it's unlikely to get any volumes as long as it isn't packaged in a nice case with physical design suitable for the living room.

2. Squeezebox compatible hardware players in a consumer attractive package is unlikely to happen, mainly because nobody is maintaining the server and Logitech will likely block such player from mysqueezebox.com as soon as it has enough volumes to increase the load on mysqueezebox.com. On top of this such player can't advertize support for online streaming services without an agreement with Logitech because Logitech might shutdown mysqueezebox.com in two years and I would be really surprised if they would be interested in license mysqueezebox.com usage to a third party player provider.

3. Consumer attractive players with similar functionality as Squeezebox but not compatible with the Squeezebox ecosystem is also likely going to happen, if there is a need and people are willing to pay, someone will usually provide a suitable product, that's how the market works, it's just a matter of time.

So basically if someone in the community wants to do something, it needs to be alternative 1 or 3, where 1 will be useful for geeks/enthusiasts but not for the masses.

epoch1970
2013-01-20, 05:14
perhaps we need to settle on one or a small number of recommended devices and package for them.
Certainly.
Who would guess "sata_sil.slow_down=1" is a solution to audio glitches ?

dustinsterk
2013-01-20, 14:51
I'm not sure whether we can turn this into a community product, but my personal view is that an effective Squeezebox replacement for the community can be made from a small existing arm based device + an external usb dac. This means all the audio engineering can be part of the dac and you can spend from $5 to $5000 based on your preference....

The device itself is probably based on something already available such as an android stick, raspberry pi or other such device - perhaps we need to settle on one or a small number of recommended devices and package for them. The one thing that most devices have now with hdmi, so a user interface using hdmi + control over that is probably required/sensible. This is not a mass market consumer product, but it gets us to a very viable solution for community enthusiasts... (and focusses much of the effort on software and packaging rather than hardware design and the necessary volumes this brings)

Squeezelite part of my steps in this direction. I'd like to look at UI solutions, perhaps integration with XBMC or alternative user interfaces hdmi - any takers?

It appears the consensus of most is that a "new device" built from the ground up would be too time consuming and possibly the market to the masses is not there. So to Triodes point as well as others, what about looking into existing ARM based products and pairing them with a nice external DAC for the use with squeezelite?

I have done some research on new and upcoming devices. I found the following:

Allwinner A10 Device from Rhombus-Tech (still under development):
http://rhombus-tech.net/allwinner_a10/

Cubieboard:
http://cubieboard.org/
http://www.aliexpress.com/item/cubieboard-1GB-ARM-Cortex-A8-Allwinner-A10-luxury-package-including-accessory-free-shipping/731449083.html

Hackberry (maybe really nice since it has wifi built in):
https://www.miniand.com/products/Hackberry%20A10%20Developer%20Board

MiniX (Has IR as well)
http://www.aliexpress.com/item/NEW-MiniX-MK805-Allwinner-A10-Android-4-0-RAM-1GB-ROM-4GB-Mini-PC-TV-Box/632885305.html
http://dx.com/p/mini-android-2-3-hd-1080p-network-media-player-w-wi-fi-hdmi-usb-av-tf-blue-134679

Other "set top" products that could work:
http://www.aliexpress.com/item/New-Google-Android-4-0-ICS-Internet-TV-Box-WIFI-Media-Player-1080P-Full-HD-HDTV/530565258.html
http://dx.com/p/compact-hd-1080p-2-5-sata-hdd-media-player-with-hdmi-usb-host-sd-av-out-coax-black-57177
http://dx.com/p/mele-1080p-android-2-3-internet-tv-set-top-box-w-wifi-optical-3-x-usb-hdmi-av-lan-sd-119913

epoch1970
2013-01-21, 05:12
Well I didn't look a *all* the links above.

I'd like to see a platform with clean audio out (SPDIF first and USB second. USB audio is too finicky IMHO) and an array of ports that allows to add peripherals.

- I would go for a VFD or (large) e-paper screen+controller in an instant (or show me a square 12" PC monitor.)
- Possibility to integrate home automation (IR Blaster and more)
- I think I'd like to see how a second line out (IR Blaster) works with a vocal UI (I guess I should test w/ squeezeslave for that); I like the RFID tag reader idea (thread (http://forums.slimdevices.com/showthread.php?97891-Controlling-Squeezebox-equipment-by-RFID-(Blog-in-German-language).)
- Some processor capable of computing audio room correction ?
- A local alarm clock module, capability to run on batteries, possibility to integrate/control a digital amp, line in support (Radio/Boom replacement)
- Automagic wireless mesh networking (control channel at least) ?
- The all-important iThing integration (to the extent of what's possible)

Given my current experience with the PC engines Alix, I think mixing server capability with player capability is difficult (I/O and CPU spikes.) A recommended ~5W server package (preferably with sata/e-sata capability) could go along the player package.

The RasPi can do many of the things above, AFAIK, and should have one interesting characteristic, same as "pro" devices: a longer lifecycle compared to consumer devices. I don't think it is reasonable to choose a platform that will fade away in 12 months, as many consumer products do.

froth
2013-01-21, 14:12
Although I believe there is lots of talent here on the boards that could be invested in a project like this, I think the reality is that there is a difference between community build of a product versus the Olive approach of a crowd funded product.

With that you need a company that will do everything from hiring the right people to do the design and build out of the product and as well as initiate all the necessary marketing and sales plans and objectives.

I for one am monitoring the Olive One product and project carefully. I see it as a potential replacement down the road for my squeeze environment.

It will all come down to the execution and delivery to market.

Sure there are some things I see that I would like different with Olive One. The biggest is a headless product. I for one cant see wanting to have a big circle device in every room. The touch was more the footprint that I liked and even that just a receiver is all I wanted in some rooms.

But I like that larger display for the wife factor. Even though I have spent hours with my wife using Ipeng she still get's it mixed up from time to time. What I end up doing is syncing a few devices in the house to a boom I have and then doing presets on the buttons for the 4 or 5 music sources she likes.

JohnSwenson
2013-01-22, 16:57
Hi guys,
I want in on this! I have been thinking a lot about it over the last few months. I am well accomplished at the hardware design part of this. I'm not sure most of you are aware of this but I do part time consulting for high end hiFi companies wanting to get into digitaal audio, I have lots of hardware experience doing just what this project is about and making it into products for low volume production.

There seems to be an assumption that you need very high volumes to get low prices, this is not really the case. You need high volumes to get REALLY low price, but medium range prices is can be had for fairly low volumes. For example something along the complexity of the Touch main board, can be manufactured for around $125 in 25 quantity, thats board, parts and assembly. That does NOT include the case, full assembly etc, just the board. At 50 quantity you can get down to $100 a board.

I have done designs using off the shelf boards and ones that I have done the whole thing from scratch, my current thinking is that for more than a couple systems it actually winds up being cheaper to do the whole thing from scratch, that way you get EXACTLY what you want. When using an off the shelf board you have to try and shoehorn your design into sombody elses vision, which rarely matches yours exactly.

For example, some people around here have mentioned things like IR remotes, if your chosen existing board doesn't have the capability, you either live without it or you have to add a board that does it, and figure out how to connect that into some port on the existing board. When you do the whole thing yourself it is MUCH easier to add things like that directly to the main board.

When doing it yourself you have a wide range of options available for including in the device, that would be very difficult to add to an existing board. For example as has been mentioned having FPGA based filters is something that is easy to add to our own board, and adds very little cost. I can easily put in a VERY high quality S/PDIF interface that will be better than just about anything out there, or even a USB output optimized for audio use.

I have been doing systems like these for many years now and the biggest time sinc has always been the UI. Since the SB line already has good external UI options, I think it makes more sense to design a product to be a black box (but with a web server for configuration etc so you get away from the Duet problems). Having a display and interface along the lines of the Touch seems to me to double or tripple the complexity of the project.

I'm a little torn on one aspect of this, my passion is for very high quality DACs, having done systems similar to this several times I CAN say that I can do a better job for less money building very good DACs into the project than you can get by buying external DACs. It doesn't HAVE to be an either or. I can do a two board system, one board has the main guts and digital audio interfaces (S/PDIF USB) and another board that plugs in which has the DACs (it does NOT connect to the S/PDIF or USB). So if you want to spend the extra $400 you can get audio quality that will out perform external DACs costing many thousands. It is just so much easier to do a really good job of a DAC if you can build it into the architecture of the main system.

Things I am NOT good at: industrial design, please don't ask me to design a really good looking case for this!

John S.

JJZolx
2013-01-22, 17:07
John, do you have experience designing a computer that includes a DAC? Or would the idea be to take some reference ARM design and basically design and build a DAC on the same board or on a daughter board?

Than what about the writing of firmware? Would you handle that as well?

Would you see this as basically mimicking a Touch, and then use the Lua code from that product?

chill
2013-01-22, 17:09
Hi guys,
I want in on this!

Great news - I can't have been the only one to think "this sounds like a job for John Swenson" when Dustin posted his original suggestion :). A version of the Duet Receiver, with a web interface and the option of a top quality DAC, seems like an excellent way to get started. Count me in for a bit of 'community funding'.

garym
2013-01-22, 19:52
Great news - I can't have been the only one to think "this sounds like a job for John Swenson" when Dustin posted his original suggestion :). A version of the Duet Receiver, with a web interface and the option of a top quality DAC, seems like an excellent way to get started. Count me in for a bit of 'community funding'.

+1000

erland
2013-01-22, 22:38
Would you see this as basically mimicking a Touch, and then use the Lua code from that product?

For a headless box there isn't any need to take any lua code from the Touch.

At the moment the easiest would be: Linux based OS + Squeezelite (or squeezeslave)
In the future this can be adapted to: Linux based OS + the player software of your choice

As long as it's Linux based and is a headless device, there is no reason to bring in the whole Touch lua based firmware which would introduce all kinds of copyright related complication since icons and similar things isn't freely re-distributable. As long as we don't have a display on the device it's much better to base it on something more lightweight, like Squeezelite. This way it's also just the player related code that have to be adapted if we want to use the box with another system in the future, like turning it into a AirPlay receiver, UPnP renderer or even a completely new system with similar features as the Squeezebox but independent from Logitech.

Having a web server for configuration should be a piece of cake, there are plenty of people around here that can help implementing that.

Some drivers would probably have to be implemented, but as long as you choose chipsets which have Linux support I suspect most of it is already available so it's more a matter of compiling/packaging them in suitable way.

Having a display on the box would be attractive and so would IR support be, but since a UI adds a lot of complexity on the software side (and possibility also on hardware side) I would skip the display in the first iteration. If you want to make the hardware future proof, it might be reasonable to add a HDMI output so it in the future will be possible to add video drivers and output a image on a TV or external display, I'm just not sure if this would introduce a lot of extra complexity on the hardware side. If it introduce a lot of extra complexity it might be better to advice users to get an old used smart phone/tablet and put it in a docking station and use that as the display together with a suitable smartphone/tablet app.

erland
2013-01-22, 23:02
When doing it yourself you have a wide range of options available for including in the device, that would be very difficult to add to an existing board. For example as has been mentioned having FPGA based filters is something that is easy to add to our own board, and adds very little cost. I can easily put in a VERY high quality S/PDIF interface that will be better than just about anything out there, or even a USB output optimized for audio use.

Having S/PDIF interface will make it more attractive to a lot of people. There are a lot of people who already have an amplifier in their listening room, being able to just connect the device to one of the digital inputs of the amplifier will make it a lot easier than forcing everyone to acquire an external USB DAC. Making it easy for more people to use it is going to be important if you like to get more volumes in the future, with only support for USB I'm afraid you are going to be restricted to selling it to geeks and audiophiles.



I'm a little torn on one aspect of this, my passion is for very high quality DACs, having done systems similar to this several times I CAN say that I can do a better job for less money building very good DACs into the project than you can get by buying external DACs. It doesn't HAVE to be an either or. I can do a two board system, one board has the main guts and digital audio interfaces (S/PDIF USB) and another board that plugs in which has the DACs (it does NOT connect to the S/PDIF or USB). So if you want to spend the extra $400 you can get audio quality that will out perform external DACs costing many thousands. It is just so much easier to do a really good job of a DAC if you can build it into the architecture of the main system.

For someone who is satisfied with the quality of the DAC in the Touch, how much price difference would it be between a board without a DAC and a board with a DAC with similar quality as the Squeezebox Touch ?
If we assume the low volume scenario, are we talking about $400 extra or is it a lot less ?

I suspect a built-in DAC is mainly critical for people who want to connect the device to powered speakers, if you already have an external amplifier that's likely going to have digital inputs so you can just use the S/PDIF output. Based on this, I think the DAC either have to be an optional part for audiophiles (as you suggested) who aren't satisfied with the DAC in their external amplifier, or if it's included on the standard board it would have to be something which doesn't increase the price too much since its main purpose would be to be able to attract users who want to connect it to powered speakers where top notch audio quality isn't as critical as in the main listening room.

JJZolx
2013-01-22, 23:40
Maybe I'm missing something, but I see little reason to build a displayless SB replacement without an internal DAC and analog out. Otherwise, the only thing it such a device might have over the current DIY solutions built on PCs with USB output is a high quality S/PDIF out.

I would see the necessary I/O as:

- analog L/R
- optical S/PDIF
- coax S/PDIF
- USB
- ethernet
- wifi

Plus (ideally):

- IR input for basic playback control: volume, skip, play, pause, repeat, shuffle

Then I'd say leave open the possibility of some kind of USB display by adding an additional USB port. With this, there could possibly be a full UI developed at some point, as long as support existed at the server.

Which brings up the issue of... branching the server.

JJZolx
2013-01-23, 00:10
Almost forgot:

If there's no IR input then there must be a reset switch of some kind that can perform a factory reset.

With IR input, you could resort to the awkward SB method of resetting by pulling the power plug and holding some random button on the remote while you plug the power back in. Or, maybe just build the first SB with a real power switch. Even with one, the reset switch would still be welcome.

erland
2013-01-23, 00:14
Otherwise, the only thing it such a device might have over the current DIY solutions built on PCs with USB output is a high quality S/PDIF out.

I suspect we are still talking about a DIY solution or possibly a pre-packaged DIY solution, so far I haven't seen any indication in this thread that makes me think it will reach the masses. To reach the masses you really need multiple type of devices, at minimum one optimized for connection to an external amplifier and one with built-in speakers suitable for kitchen/bedroom/bathroom kind of environment.

To reach the masses you also need to reach the shelf in the stores, but that's a different topic so let's not bring that into the discussion yet.



Which brings up the issue of... branching the server.

Which would be a much bigger task, especially if we want to do it the right way and not violate license/copyrights from Logitech and other companies which own the redistribution rights. It's easy to do it if you ignore the legal problems which violating the license/copyright can cause and ignore Windows users which want the exe binaries, but doing so doesn't seem like a long term solution to me. However, having said that, it's certainly doable, the question is just if it's worth the trouble and I'm skeptical if there are enough people in the community who would be willing to do the necessary development/maintenance work for free on longer terms.

As I posted earlier in the thread:
http://forums.slimdevices.com/showthread.php?97881-Community-Funded-Squeezebox-Replacement-Would-you-be-interested&p=733887&viewfull=1#post733887
I personally still believe something that relies on LMS or even mysqueezebox.com is a temporary solution, which works for DIY hardware, but for long term survival we really need something else. So to base the box on Linux and not tie too much of it towards Logitech and LMS/mysqueezebox.com is probably a good idea to make it easier to change it to work with something else in the future.

JJZolx
2013-01-23, 00:31
I suspect we are still talking about a DIY solution or possibly a pre-packaged DIY solution, so far I haven't seen any indication in this thread that makes me think it will reach the masses. To reach the masses you really need multiple type of devices, at minimum one optimized for connection to an external amplifier and one with built-in speakers suitable for kitchen/bedroom/bathroom kind of environment.

To reach the masses you also need to reach the shelf in the stores, but that's a different topic so let's not bring that into the discussion yet.

(etc.)


You've lost me... Who's talking about "masses" or selling anything in stores?



As I posted earlier in the thread:

I personally still believe something that relies on LMS or even mysqueezebox.com is a temporary solution, which works for DIY hardware, but for long term survival we really need something else. So to base the box on Linux and not tie too much of it towards Logitech and LMS/mysqueezebox.com is probably a good idea to make it easier to change it to work with something else in the future.


I haven't addressed mysb.com functionality, but how can a Squeezebox replacement NOT rely on LMS or another server that implements SlimProto? If it doesn't, then it's not a Squeezebox.

John's post talks of circuit boards an IR input, so I presume that he's talking about building something that resembles and operates like a Squeezebox. We're no longer talking about taking a Raspberry Pi or other off-the-shelf computer and making it work like a Squeezebox to feed a USB DAC. For the most part, that's been done. My post above simply tries to outline what I feel would be the minimum required I/O of an SB replacement. Apart from the USB, it's not much different than the old Receiver.

pippin
2013-01-23, 01:03
Adding audio beyond USB audio for me mainly brings up the question of drivers and codecs.
Since you'd not be able to afford commercial codecs and patent licenses for a DIY activity you'd need to be able to go with something that fits into a standard open-source architecture, with other words, you need ALSA drivers.
Would a custom audio solution use a chipset that comes with ALSA drivers?

On the server side the main point is that you probably need to branch to be able to supply your own firmware which in turn means you need to de-brand LMS but I might be wrong here.

The one thing where I don't see an issue is the USB display. That's IMHO unrelated to the server and purely a client-side activity since you can drive the thing through the server-side SqueezePlay menus.
You can get around a lot of the software license issues with open source codecs but not around the patent problem. Also, some of the open source codecs violate patents in some legislations which means you can't always re-distribute them, even if you whole own software was under GPL, which it isn't if you want to use any of the Logitech code (which is open source but not GPL'ed). GPL can be pretty much of a nuisance if you go into re-distribution.

dustinsterk
2013-01-23, 09:49
Hi guys,
I want in on this! I have been thinking a lot about it over the last few months. I am well accomplished at the hardware design part of this. I'm not sure most of you are aware of this but I do part time consulting for high end hiFi companies wanting to get into digitaal audio, I have lots of hardware experience doing just what this project is about and making it into products for low volume production.

There seems to be an assumption that you need very high volumes to get low prices, this is not really the case. You need high volumes to get REALLY low price, but medium range prices is can be had for fairly low volumes. For example something along the complexity of the Touch main board, can be manufactured for around $125 in 25 quantity, thats board, parts and assembly. That does NOT include the case, full assembly etc, just the board. At 50 quantity you can get down to $100 a board.

I have done designs using off the shelf boards and ones that I have done the whole thing from scratch, my current thinking is that for more than a couple systems it actually winds up being cheaper to do the whole thing from scratch, that way you get EXACTLY what you want. When using an off the shelf board you have to try and shoehorn your design into sombody elses vision, which rarely matches yours exactly.

For example, some people around here have mentioned things like IR remotes, if your chosen existing board doesn't have the capability, you either live without it or you have to add a board that does it, and figure out how to connect that into some port on the existing board. When you do the whole thing yourself it is MUCH easier to add things like that directly to the main board.

When doing it yourself you have a wide range of options available for including in the device, that would be very difficult to add to an existing board. For example as has been mentioned having FPGA based filters is something that is easy to add to our own board, and adds very little cost. I can easily put in a VERY high quality S/PDIF interface that will be better than just about anything out there, or even a USB output optimized for audio use.

I have been doing systems like these for many years now and the biggest time sinc has always been the UI. Since the SB line already has good external UI options, I think it makes more sense to design a product to be a black box (but with a web server for configuration etc so you get away from the Duet problems). Having a display and interface along the lines of the Touch seems to me to double or tripple the complexity of the project.

I'm a little torn on one aspect of this, my passion is for very high quality DACs, having done systems similar to this several times I CAN say that I can do a better job for less money building very good DACs into the project than you can get by buying external DACs. It doesn't HAVE to be an either or. I can do a two board system, one board has the main guts and digital audio interfaces (S/PDIF USB) and another board that plugs in which has the DACs (it does NOT connect to the S/PDIF or USB). So if you want to spend the extra $400 you can get audio quality that will out perform external DACs costing many thousands. It is just so much easier to do a really good job of a DAC if you can build it into the architecture of the main system.

Things I am NOT good at: industrial design, please don't ask me to design a really good looking case for this!

John S.


Hello John,
This is VERY exciting news. I am not 100% sure where to go with this and the next steps. My overall feeling is that there are many users that want a device.... but still questions if there is a "market" for it. I feel that if we assemble a small group, put together the design and implement a "kickstarter" type project, we will get the interest from this community. I would assume we could easily get over 50 - 100 orders on the first batch if the price was right based on this thread already having 31 pages (http://forums.slimdevices.com/showthread.php?96191-Now-the-Squeezebox-is-dead-what-would-your-next-system-be-And-why/page31).

This leads to a much larger question of legalities with Logitech, creation of an LLC or other company structure, how we further market, etc. Erland has already created the developers group. I am wondering if we should take this entire discussion to that group and the parties that have real interest can join.

Thoughts?

Thanks!
--Dustin

erland
2013-01-23, 09:52
You've lost me... Who's talking about "masses" or selling anything in stores?

Sorry, I think my mind went a bit ahead of the thread :-)
When reading John's post again it's pretty clear that he is talking about a low volume solution which doesn't have to be sold through local stores.



I haven't addressed mysb.com functionality, but how can a Squeezebox replacement NOT rely on LMS or another server that implements SlimProto? If it doesn't, then it's not a Squeezebox.

John's post talks of circuit boards an IR input, so I presume that he's talking about building something that resembles and operates like a Squeezebox. We're no longer talking about taking a Raspberry Pi or other off-the-shelf computer and making it work like a Squeezebox to feed a USB DAC. For the most part, that's been done. My post above simply tries to outline what I feel would be the minimum required I/O of an SB replacement. Apart from the USB, it's not much different than the old Receiver.

In my mind:
Squeezebox replancement = A music streaming device that provides similar features as the Squeezebox (preferably but not necessarily compatible with existing Squeezeboxes)

However, I think a DIY solution could make sense to some existing Squeezebox enthusiasts who have a desperate need to enhance their existing system, relying on LMS makes sense if you want to do something simple that works as a temporary solution until the market catches up with the needs we have. In my mind it doesn't really make sense to even package software and hardware together for this kind of system, just let each user buy the parts, load the software on it and assemble the device themselves. It would avoid the codec licensing issue pippin mentions, since you are just selling a circuit board and not a music streaming device.

Still, if you just want a temporary solution, why not just get a used Squeezebox from eBay ?
Surely there will be people selling their old Squeezeboxes on eBay during the years to come if people are still willing to buy it for the same price as a new one.
I guess it could make sense if you like to experiment with DIY solutions, just because it's fun, but if not I can't really see the need unless you also handle the long term issues.

If you want to do something more long term, you really need to handle LMS and mysqueezebox.com maintenance and then it will become a much bigger thing and in this case it might even be better to start over and build something with similar functionality instead of relying on LMS which have 10 years of architectural inheritance. Reusing someone elses code in a new system isn't always the easiest way to do things, in my experience you really earn most time by reusing functional specifications and possibly architecture/design and protocols if it's good, reusing code only really makes sense if you don't plan to change it or you already understand the code in detail. Of course, for LMS there isn't really any functional specifications to reuse and the protocols are barely documented, so the question is if it's really worth the trouble to try to branch and re-brand it.

erland
2013-01-23, 10:10
Adding audio beyond USB audio for me mainly brings up the question of drivers and codecs.

Don't you have codec/patent licensing issues also with USB audio ?
Isn't the issue related to MP3 codecs and similar ? Won't those be needed also if you use USB audio ?

However, as I said in my previous post a few minutes ago, I think it's best to just do a real DIY solution where each user buys the parts and assembles it themselves and load the necessary software on it, then you could probably avoid the codec/patent issues as you are just selling a circuit board without any software, or am I missing something ?

You would of course still need drivers, but hopefully those are already available if you select hardware components which already have Linux drivers.



On the server side the main point is that you probably need to branch to be able to supply your own firmware which in turn means you need to de-brand LMS but I might be wrong here.

For a DIY solution you would probably not load firmware through LMS. The real Logitech Squeezebox devices in the system would get firmware from LMS, the DIY devices would get their firmware through a SDHC card, USB stick or some other way. We aren't talking mass market convenience, we are talking DIY solution for enthusiasts as I've understood it.

One reason to re-brand LMS is if you want to ensure long term survival and not risk that Logitech will stop maintaining it in a year or two.
Another reason could be that you want to add new features to the core parts of LMS since this won't happen as long as Logitech maintains it. Most things can probably be added as plugins and won't need a community maintained LMS, but if you want to really revolutionize it, you would probably need to branch it since new features would be needed in the core parts.

pippin
2013-01-23, 10:26
The advantage of using USB audio is that it usually comes with ALSA driver support so you can use standard open source codec distributions.
Still doesn't help you if you want to sell the thing as a working unit but for a DIY platform that just needs a software distribution to be added to it it gets you around having to develop drivers, which isn't the most convenient thing to do.

I have no idea whether the same result can also be achieved by using a standard chipset, hence my question.

dyohn
2013-01-23, 10:30
Well, this solution worked for me. USB DAC and control via iPad and I'm rocking.

http://vortexbox.org/content/149-Logitech-SqueezeBox-replacement-for-under-30

erland
2013-01-23, 10:31
This leads to a much larger question of legalities with Logitech, creation of an LLC or other company structure, how we further market, etc. Erland has already created the developers group. I am wondering if we should take this entire discussion to that group and the parties that have real interest can join.

Thoughts?

I agree, discussing legal strategies and potential company structure is better handled in private.

If you want to use the private developers group I created, that's fine with me, it's linked to in the forth post in this thread.
Just be aware that I'm going to keep it small and only accept members who I trust and who have already shown their abilities that makes me think they can help with development or hardware design, so if you want to check for interest regarding different features or who want to donate money to the project, that kind of discussion is probably better handled in the public forum or asking them to mail you directly.

JJZolx
2013-01-23, 10:32
Sorry, I think my mind went a bit ahead of the thread :-)
In my mind:
Squeezebox replancement = A music streaming device that provides similar features as the Squeezebox (preferably but not necessarily compatible with existing Squeezeboxes)

New players like this are being released by consumer electronics and audio companies almost weekly, typically relying on DLNA network servers for local content. But with few of features that the _software_ of the Squeezebox system affords. Things like synched playback, plugins and broad audio format compatibility. I'm not sure I see the point in producing another one. Surely by now there's a player available for everyone if those limitations are of no importance.

If you want many of the same features as Squeezebox, you're going to have to make the system reliant upon some kind of local server. Do you want to write something like Squeezebox Server over again from scratch? SBS isn't perfect, but it represents many man-years of work. (And then I'd have to ask: How would this system complement my existing Squeezebox infrastructure and investment? If it's completely independent of it, then I fail to see much appeal.)

My understanding is that as far as copyright issues are concerned, the only thing prevented would be the re-distribution of Squeezebox firmware. Which seems like a minor concern when you consider that the firmware for older Squeezeboxes is no longer being updated and new firmware for SqueezePlay devices is downloaded on the fly. As far as codecs are concerned: is Logitech actually licensing any of the distributed software? They don't even distribute LAME with the server for MP3 encoding.

dyohn
2013-01-23, 10:34
Like I said on the previous page, it already exists. http://vortexbox.org/content/149-Logitech-SqueezeBox-replacement-for-under-30

erland
2013-01-23, 11:03
I'd have to ask: How would this system complement my existing Squeezebox infrastructure and investment? If it's completely independent of it, then I fail to see much appeal.)

Correct, unless you can load custom firmware to your existing Squeezeboxes and make them work with the new system.
Based on my own experience, I know this is reasonable on the Touch/Radio, but it's probably going to be a bit more complex on the older devices.

Also, obviously it only makes sense to do a completely new system if the new system can be sold to the masses, if you plan to only sell a few hundred devices you should just base the solution on LMS/mysqueezebox.com.



My understanding is that as far as copyright issues are concerned, the only thing prevented would be the re-distribution of Squeezebox firmware. Which seems like a minor concern when you consider that the firmware for older Squeezeboxes is no longer being updated and new firmware for SqueezePlay devices is downloaded on the fly. As far as codecs are concerned: is Logitech actually licensing any of the distributed software? They don't even distribute LAME with the server for MP3 encoding.

From my memory, the copyright/re-distribution issues are at least:
- Player firmware
- All artwork (buttons, icons, logos and similar things)
- Windows installer (I think it's copyrighted to Logitech, but the reason for that is probably mainly because they don't have permission to let anyone else redistribute it)
- exe binaries for Windows (I think you need the OEM version of ActiveState Perl, not sure what it costs)
- I think someone also mentioned that some codecs were a problem, don't remember which ones
- I'm not sure about the license status of the Windows control panel applet.

You can choose to ignore the legal issues and my guess is that Logitech probably won't care unless you do something that hurts their business. If you are lucky the companies owning the rights for codecs, Windows installer and exe binaries for perl won't notice you are breaking their license. If they do care, you could end up in legal trouble, but I guess someone doing it would have to make a judgement if it's worth the risk or not. As long as you only distribute it to geeks you are probably fine, if you distribute it to all Squeezebox users and advertise it, the risk of getting caught becomes a bit bigger.

Making a completely legal fork is going to be a bit of work, especially if you like to satisfy Windows users.
Andy mentioned in some thread that building all the CPAN perl modules on Windows can be a bit of a challenge, so except for the above I suspect this will introduce another complexity if you like to keep CPAN modules updated and satisfy Windows users. The svn/git version works because Logitech have already pre-built the CPAN binaries and commited them to svn/git.

pippin
2013-01-23, 11:18
My understanding is that as far as copyright issues are concerned, the only thing prevented would be the re-distribution of Squeezebox firmware. Which seems like a minor concern when you consider that the firmware for older Squeezeboxes is no longer being updated and new firmware for SqueezePlay devices is downloaded on the fly. As far as codecs are concerned: is Logitech actually licensing any of the distributed software? They don't even distribute LAME with the server for MP3 encoding.

They do license a lot for the players.
There are two aspects here:
Software licenses (probably for mp3, WMA, and AAC) and patent fees (at least mp3 and WMA, not sure about AAC). Both come with a fixed minimum cost that makes them prohibitive at low volumes.

TheLastMan
2013-01-23, 11:51
Maybe I'm missing something, but I see little reason to build a displayless SB replacement without an internal DAC and analog out. Otherwise, the only thing it such a device might have over the current DIY solutions built on PCs with USB output is a high quality S/PDIF out.

I would see the necessary I/O as:

- analog L/R
- optical S/PDIF
- coax S/PDIF
- USB
- ethernet
- wifi
+1

Everybody who reads these forums is an "enthusiast", but few are "geeks". Most of us could cope with buying a box and following some step-by-step instructions to install a pre-packaged linux distro and software player (similar to the Vortexbox project) but that would be about the limit.

Remember some of us have wives and an ugly "Pogoplug" device with a totally uncoordinated USB DAC hanging off the back won't cut the "decor" mustard. Ideally the thing should be at least passably attractive and small enough to be nearly invisible anyway.

We were prepared to pay £150/$200+ for our Squeezeboxes so we can afford this for a replacement, so a $30 player is unnecessarily cheap! Most would be prepared to pay an extra £100 in order not to have to spend 30 hours making several attempts at "hacking" linux to get the thing to work!

Most stereo "hi-fi" amps do not have integrated DACs so the device will definitely need a DAC, but it only needs to be as good as the Receiver or Touch. If you want better you can buy a hi-fi DAC (as opposed to a computer audio DAC).

I really like the look of the CuBox:
http://www.solid-run.com/products/cubox

In design terms it is so nearly there. Add a halfway decent audio chip and it would be a done deal for me if you could download pre-packaged software to go on it.

JJZolx
2013-01-23, 11:56
From my memory, the copyright/re-distribution issues are at least:
- Player firmware
- All artwork (buttons, icons, logos and similar things)
- Windows installer (I think it's copyrighted to Logitech, but the reason for that is probably mainly because they don't have permission to let anyone else redistribute it)
- exe binaries for Windows (I think you need the OEM version of ActiveState Perl, not sure what it costs)
- I think someone also mentioned that some codecs were a problem, don't remember which ones
- I'm not sure about the license status of the Windows control panel applet.

Ok. Yeah, there are some obstacles there.

- Player firmware. As stated previously, not really a concern.

- Artwork. If SqueezePlay isn't used, then this would only be in the web UI. Drop in replacements wouldn't be hard to create for a decent graphic artist.

- Windows Installer. Another could be created. Probably one that is much faster.

- EXE for Windows. Yes, if we wanted to recreate this, the ActiveState SDK would need to be purchased and licensing (if needed) would have to be explored. Or, require users to install the free ActiveState Perl interpreter and run the Perl code. For a project like this, that's not unreasonable.

- Windows Control Panel. Not necessary. IIRC, the only thing it does that can't easily be done otherwise, is install/uninstall SBS as a Windows service. That functionality could be incorporated into the Windows installer, and you could just have users re-run the installer.

If there are codecs that require licensing, whether or not a player is based on SBS will make no difference. How does a player like Squeezelite deal with this?

erland
2013-01-23, 12:08
They do license a lot for the players.
There are two aspects here:
Software licenses (probably for mp3, WMA, and AAC) and patent fees (at least mp3 and WMA, not sure about AAC). Both come with a fixed minimum cost that makes them prohibitive at low volumes.

For those interested:
MP3: http://www.mp3licensing.com/royalty/hardware.html
AAC: http://www.vialicensing.com/licensing/aac-fees.aspx
WMA: http://www.microsoft.com/windows/windowsmedia/licensing/final.aspx

Or in summary (if my interpretation is correct), the minimum fees are:
MP3: $15 000/year as minimum
AAC: $1 000 initial setup (http://www.un4seen.com/forum/?topic=10328.0)
WMA: Not sure what the $400 000 number means, feels like way too much as an annual fee.

So basically, the alternatives are one of:
- Make a DIY device and let the user assemble it and avoid the license issues
- Base the device on hardware where the hardware manufacturer already pays the necessary codec/patent licenses.
- Hope that nobody notice that you are violating licenses (might be reasonable if you only plan to sell 500 devices and doesn't advertise it much)
- Sell to the masses
- Focus on OGG/FLAC and avoid codecs/patents which requires a license.

pippin
2013-01-23, 12:23
MP3 is $15.000 (as of your link) minimum per year.

I believe all text in SqueezePlay/LMS is also copyrighted, changing this would probably be the biggest activity.

erland
2013-01-23, 12:25
If there are codecs that require licensing, whether or not a player is based on SBS will make no difference. How does a player like Squeezelite deal with this?

Not sure how it works now, but initially I believe it required you to install lame on the server.
http://forums.slimdevices.com/showthread.php?97766-Announce-Local-Player-plugin-and-Squeezelite-for-Linux-Windows-OSX&p=731954&viewfull=1#post731954

Not sure how/if it would cause more issues in a scenario where someone bundled squeezelite pre-installed on a hardware box.

Licensing will be an issue on consumer packaged hardware unless:
- You sell to the masses so the initial/annual license costs are small compared to your revenue
or
- Someone else has already payed the license for you (if I've understood correctly this can be the case for some audio circuits, at least in theory)

The issues regarding licenses only cause problem if you only plan to sell a few devices. The per device cost is often not the issue, it's the initial/annual minimal costs that cause problems.

erland
2013-01-23, 12:33
- EXE for Windows. Yes, if we wanted to recreate this, the ActiveState SDK would need to be purchased and licensing (if needed) would have to be explored. Or, require users to install the free ActiveState Perl interpreter and run the Perl code. For a project like this, that's not unreasonable.

The problem is still the CPAN modules, Logitech compiles these for newer ActiveState versions regularly so you never see the issue when you run svn/git version because they have commited binaries in svn/git.

I don't think compiling them would require a OEM license but as I've understood from Andy it requires a bit of work to setup the build environment to compile them.

ActiveState have a tendency to remove older perl versions and only offer the latest or two latest ones for free, so for it to work for new users you need to ensure you have always compiled the CPAN modules towards the latest version available from ActiveStatue.

So I think Windows support will be a bit of work independent if you redistribute compiled exe's or just distribute perl code with compiled CPAN modules.

But maybe we can create a Linux based server box also to get around that issue or just recommend users to get a VortexBox Appliance.

dustinsterk
2013-01-23, 12:38
Not sure how it works now, but initially I believe it required you to install lame on the server.
http://forums.slimdevices.com/showthread.php?97766-Announce-Local-Player-plugin-and-Squeezelite-for-Linux-Windows-OSX&p=731954&viewfull=1#post731954

Not sure how/if it would cause more issues in a scenario where someone bundled squeezelite pre-installed on a hardware box.

Licensing will be an issue on consumer packaged hardware unless:
- You sell to the masses so the initial/annual license costs are small compared to your revenue
or
- Someone else has already payed the license for you (if I've understood correctly this can be the case for some audio circuits, at least in theory)

The issues regarding licenses only cause problem if you only plan to sell a few devices. The per device cost is often not the issue, it's the initial/annual minimal costs that cause problems.


We could have two versions of the product:
1) A 'DIY' device which would be cheaper and require the user to load the software.
2) A 'Ready to Go' version which includes the licensing costs and is a little more expensive.

Triode
2013-01-23, 12:46
Anyone reading this thread should try Squeezelite on a CuBox or a Rasberry Pi, Pogoplug....

My original motivation for squeezelite is for a headless linux playback engine which emulates as many features as possible of the Squeezebox hardware so that it can integrate with existing LMS, but run on a small linux device and drive a usb dac. I think its close to release status and has a few users at present..... I.e. exactly what we could be talking about here...

I think we can easliy do something which is a usable player for people by constraining the scope:

1) target a small number of linux devices and create some standard install scripts/images for them
2) start with a headless system (no ui, but target a device with hdmi interface as we can expand into hdmi based user interface relatively easliy); users can use LMS web interface, iPeng, SqueezePad etc to controll it
3) start with usb audio as this means we can use off the shelf hardware and let the user select the level of audio engineering they want from $5 upwards...
4) assume the user has some involvement in the install process and we are not charging for the solution, so this allows the user to download standard linux codecs without concerns over patent licensing...

Later we can add a user interface and potentially integrate server functions.

For me a Cubox is making an excellent but expensive player. A Raspberry Pi is cheaper, but has problems with USB dac compatiblity (hopefully to be resolved by the Pi developers). Both provide usb out, ethernet and wifi via usb and hdmi for a future user interface....

erland
2013-01-23, 12:49
We could have two versions of the product:
1) A 'DIY' device which would be cheaper and require the user to load the software.
2) A 'Ready to Go' version which includes the licensing costs and is a little more expensive.

I suspect:
- The people who is able to use the DIY device are those who don't have an issue with a higher price (geeks don't care if it costs a bit as long as it's cool :-) )
- The people who isn't able to use the DIY device is likely those who want a lower price

So I would just focus on either the DIY device and ignore people who can't install it or focus only on the consumer device and hope to get more customers and make the licensing costs less of a problem. If I've understood it correctly, you would have to pay the minimum $15 000 for the MP3 license before you sell the first device, so you need to ensure you have funding for this if you want to do the "Ready to Go" device, if you only sell 100 of them the first year the MP3 license adds $150/device, so you need to ensure you have packaged it in a nice case so it can sell more than hundred devices per year.

dustinsterk
2013-01-23, 12:56
+1

Everybody who reads these forums is an "enthusiast", but few are "geeks". Most of us could cope with buying a box and following some step-by-step instructions to install a pre-packaged linux distro and software player (similar to the Vortexbox project) but that would be about the limit.

Remember some of us have wives and an ugly "Pogoplug" device with a totally uncoordinated USB DAC hanging off the back won't cut the "decor" mustard. Ideally the thing should be at least passably attractive and small enough to be nearly invisible anyway.

We were prepared to pay £150/$200+ for our Squeezeboxes so we can afford this for a replacement, so a $30 player is unnecessarily cheap! Most would be prepared to pay an extra £100 in order not to have to spend 30 hours making several attempts at "hacking" linux to get the thing to work!

Most stereo "hi-fi" amps do not have integrated DACs so the device will definitely need a DAC, but it only needs to be as good as the Receiver or Touch. If you want better you can buy a hi-fi DAC (as opposed to a computer audio DAC).

I really like the look of the CuBox:
http://www.solid-run.com/products/cubox

In design terms it is so nearly there. Add a halfway decent audio chip and it would be a done deal for me if you could download pre-packaged software to go on it.

I do agree that the new version must be visually attractive, with or without a screen (to be decided later), or very small to hide the clutter (unlike the pogoplug versions, etc). I also like the approach of having HDMI out and allowing this new device to display now playing information on your choice ouput devices (TV, Monitor, etc). The CuBox does look to be close, just without the DAC. I would look to John for suggestions and input to keep costs in check, etc.

dustinsterk
2013-01-23, 13:08
Anyone reading this thread should try Squeezelite on a CuBox or a Rasberry Pi, Pogoplug....

My original motivation for squeezelite is for a headless linux playback engine which emulates as many features as possible of the Squeezebox hardware so that it can integrate with existing LMS, but run on a small linux device and drive a usb dac. I think its close to release status and has a few users at present..... I.e. exactly what we could be talking about here...

I think we can easliy do something which is a usable player for people by constraining the scope:

1) target a small number of linux devices and create some standard install scripts/images for them
2) start with a headless system (no ui, but target a device with hdmi interface as we can expand into hdmi based user interface relatively easliy); users can use LMS web interface, iPeng, SqueezePad etc to controll it
3) start with usb audio as this means we can use off the shelf hardware and let the user select the level of audio engineering they want from $5 upwards...
4) assume the user has some involvement in the install process and we are not charging for the solution, so this allows the user to download standard linux codecs without concerns over patent licensing...

Later we can add a user interface and potentially integrate server functions.

For me a Cubox is making an excellent but expensive player. A Raspberry Pi is cheaper, but has problems with USB dac compatiblity (hopefully to be resolved by the Pi developers). Both provide usb out, ethernet and wifi via usb and hdmi for a future user interface....

Question to John, and this maybe too early to answer: A device similar to the Cubox (design/features), adding the DAC, what can be expected from time/money invested?

JJZolx
2013-01-23, 13:18
Question to John, and this maybe too early to answer: A device similar to the Cubox (design/features), adding the DAC, what can be expected from time/money invested?

He mentioned $100 for the mainboard in small quantities. Although that sounds quite reasonable, that's before adding a CPU, memory, wifi card, antennas, audio components, connectors, power supply, case and assembly.

Can something like this be made to work with 'stock' LMS, or does it require involvement from someone maintaining the server to add support for a new type of Squeezebox device?

epoch1970
2013-01-23, 13:23
We were prepared to pay £150/$200+ for our Squeezeboxes so we can afford this for a replacement, so a $30 player is unnecessarily cheap! Most would be prepared to pay an extra £100 in order not to have to spend 30 hours making several attempts at "hacking" linux to get the thing to work!
+1
- I will pay (in advance if necessary) the former price of an SB3 to get the same service in a new device. Count me in for 1 (and up to 3 if we're talking about a Boom replacement.) The thing has to be well thought, promise a long lifecycle, and shall not come in a sandwich box. It has to work fine with my current SBs.
- I could pay around $70 (that's with all accessories) for a software player properly packaged on an off-the-shelf platform, controlled via iPeng. But probably only once my SBs start dying…

A reasonably priced dedicated device, part of an SB-compatible system, has a lot of appeal to me.

(I looked at some Olive One videos. I will wait for the marketing haze to lift; But for the moment, surely it does not appear as SB compatible and that's not good for me --DLNA will not enter my home. And second, I hope for them they will be able to pump up performance of the seemingly obligatory color display. Competing with smartphones is difficult, as we've seen.)

lrossouw
2013-01-23, 14:23
Love the discussion here! I'm in on a device. Will probably mess round with R Pi and squeezelite until then. I think starting with LMS based device is the way to go. I think displays are over rated. Rather HDMI out for that. I rarely look at my touches these days. Always on my tab or phone first. I think John Swenson's technical involvement would be great.

erland
2013-01-23, 14:42
He mentioned $100 for the mainboard in small quantities. Although that sounds quite reasonable, that's before adding a CPU, memory, wifi card, antennas, audio components, connectors, power supply, case and assembly.

Can something like this be made to work with 'stock' LMS, or does it require involvement from someone maintaining the server to add support for a new type of Squeezebox device?
It will work with stock LMS.

dustinsterk
2013-01-23, 15:09
It will work with stock LMS.


As previously discussed, I see a perfect marriage of this new device with Vortexbox. It is a perfect LMS platform which I am a big fan of and use everyday!

Mark Miksis
2013-01-23, 15:55
They do license a lot for the players.
There are two aspects here:
Software licenses (probably for mp3, WMA, and AAC) and patent fees (at least mp3 and WMA, not sure about AAC). Both come with a fixed minimum cost that makes them prohibitive at low volumes.

Note also that, as per Michael, Logitech pays some money to TuneIn for each player sold. It's not clear how much or exactly what this enables that is not available from TuneIn for free.

erland
2013-01-23, 16:21
Note also that, as per Michael, Logitech pays some money to TuneIn for each player sold. It's not clear how much or exactly what this enables that is not available from TuneIn for free.

I'm not sure it's available for free at all for streaming devices, as I've understood you need a partner agreement to get access to the API these days.

pssc
2013-01-24, 09:18
1) target a small number of linux devices and create some standard install scripts/images for them
2) start with a headless system (no ui, but target a device with hdmi interface as we can expand into hdmi based user interface relatively easliy); users can use LMS web interface, iPeng, SqueezePad etc to controll it
3) start with usb audio as this means we can use off the shelf hardware and let the user select the level of audio engineering they want from $5 upwards...
4) assume the user has some involvement in the install process and we are not charging for the solution, so this allows the user to download standard linux codecs without concerns over patent licensing...



I'd support this approach I think the PI would make an inexpensive platform for people, I have squeeze play work already on this platform with stable audio, with appropriate packages a pre installed image or an install from the pi base image should be doable,

Phill.

JohnSwenson
2013-01-24, 14:26
Some quick thinking and back of envelope figures comes up with the following:

One board which has CPU, main memory (DDR2 or DDR3), boot rom, ethernet, USB, S/PDIF out, I2S to a DAC chip, WiFi and HDMI. No onboard display, no server.

I have found some very nice new processors that do almost everything here, have linux distros ready to go which include drivers for all this (including audio for USB, I2S and S/PDIF). Quick calculations come up with $170 for board, all parts, and assembly in 25 unit quantities. Of course price goes down as quantity increases.

This does NOT include: case, power supply, antenna and final assembly.

I found a very interesting DAC chip for this. As some of you might have read in my posts, I am convinced that one of the biggest problems with getting REALLY good sound from digital audio is the compromised digital filters in DAC chip. This DAC is uniquein that it has a general purpose DSP system included which allows you to implement your own filter! (by default it uses the good old broken design that everybody uses, but you don't HAVE to use it) Using a non compromised filter will significantly improve the sound quality over what you can get from say a Touch. It also has enough power to do things like room correction filters, speaker crossovers etc. And it costs $9 in singles. It has a direct drive output so it can directly drive RCA jacks without any caps or op amps etc.

With this DSP it can easily do things such as what was done in the Boom without adding any extra circuitry. It can also do other things such as Dolby digital or DTS decoding. I would add a connector on the main board so you can add an inexpensive daugther board and get 4 more outputs, you can then have it do surround sound or digtial crossovers for triamped speaker systems. With all the processing done inside the DAC chip!

The WiFi is also rather interesting, I found a little WiFi module which has it's own processor which has a web server for configuratgion, supports bridge mode, AP mode AND has a router and DHCP server built in, all for $30. This means that not only can it connect to an existing wireless network, it can make it's OWN wireless network so you can use iPeng (or whatever) without having to have an existing network or worrying about how to connect this box and your chose remote to something else. It offloads all the wireless encryption etc from the main processor, it just looks like a wired ethernet device to the main processor (it also has a 5 port ethernet switch built in which can even do VLANs if you REALLY want to do fancy IT stuff)

Without having to do display or wifi stuff the main processor really doesn't have all that much to do, just run linux, IP stack, audio drivers and Squeezelite. It doesn't need to be a very powerful processor. There are some very nice new processors which are very low power (electrical wise, not throughput wise) which have two processors on the same chip, one which is the main processor and the other that is optimized for peripheral handling which takes care of a lot of the real time interaction with things such as the ethernet and USB, freeing up the main processor from having to deal with the low level interactions with these. The linux drivers deal with all this already.

With the low power use of everything in the system it might be quite possible to run this as a battery powered device. It's not going to be very big either, something like 3x3 inches.

How does that sound, any thoughts?

Thanks,

John S.

JackOfAll
2013-01-24, 14:33
I'd support this approach I think the PI would make an inexpensive platform for people, I have squeeze play work already on this platform with stable audio, with appropriate packages a pre installed image or an install from the pi base image should be doable,

Yes, but the Pi onboard audio leaves more than a little to be desired from a SQ perspective. And as soon as you connect a UAC2 DAC you find out that the Pi is somewhat less than desirable as a platform in that regard, as well.

JackOfAll
2013-01-24, 14:37
How does that sound, any thoughts?


I'm with you on using off-chip OS/DF. What DAC chip do you have in mind?

chill
2013-01-24, 15:28
How does that sound, any thoughts?

I hesitate to ask, but particularly in light of the self-contained wifi, is there likely to be room on the processor to run LMS too?

Triode
2013-01-24, 15:33
Yes, but the Pi onboard audio leaves more than a little to be desired from a SQ perspective. And as soon as you connect a UAC2 DAC you find out that the Pi is somewhat less than desirable as a platform in that regard, as well.

I believe this to be very dac dependant - its useless for my dac, but others have not problems.. Its a great target if the usb can be made to work..

Triode
2013-01-24, 15:44
Some quick thinking and back of envelope figures comes up with the following:

One board which has CPU, main memory (DDR2 or DDR3), boot rom, ethernet, USB, S/PDIF out, I2S to a DAC chip, WiFi and HDMI. No onboard display, no server.

I have found some very nice new processors that do almost everything here, have linux distros ready to go which include drivers for all this (including audio for USB, I2S and S/PDIF). Quick calculations come up with $170 for board, all parts, and assembly in 25 unit quantities. Of course price goes down as quantity increases.

This does NOT include: case, power supply, antenna and final assembly.

I found a very interesting DAC chip for this. As some of you might have read in my posts, I am convinced that one of the biggest problems with getting REALLY good sound from digital audio is the compromised digital filters in DAC chip. This DAC is uniquein that it has a general purpose DSP system included which allows you to implement your own filter! (by default it uses the good old broken design that everybody uses, but you don't HAVE to use it) Using a non compromised filter will significantly improve the sound quality over what you can get from say a Touch. It also has enough power to do things like room correction filters, speaker crossovers etc. And it costs $9 in singles. It has a direct drive output so it can directly drive RCA jacks without any caps or op amps etc.

With this DSP it can easily do things such as what was done in the Boom without adding any extra circuitry. It can also do other things such as Dolby digital or DTS decoding. I would add a connector on the main board so you can add an inexpensive daugther board and get 4 more outputs, you can then have it do surround sound or digtial crossovers for triamped speaker systems. With all the processing done inside the DAC chip!

The WiFi is also rather interesting, I found a little WiFi module which has it's own processor which has a web server for configuratgion, supports bridge mode, AP mode AND has a router and DHCP server built in, all for $30. This means that not only can it connect to an existing wireless network, it can make it's OWN wireless network so you can use iPeng (or whatever) without having to have an existing network or worrying about how to connect this box and your chose remote to something else. It offloads all the wireless encryption etc from the main processor, it just looks like a wired ethernet device to the main processor (it also has a 5 port ethernet switch built in which can even do VLANs if you REALLY want to do fancy IT stuff)

Without having to do display or wifi stuff the main processor really doesn't have all that much to do, just run linux, IP stack, audio drivers and Squeezelite. It doesn't need to be a very powerful processor. There are some very nice new processors which are very low power (electrical wise, not throughput wise) which have two processors on the same chip, one which is the main processor and the other that is optimized for peripheral handling which takes care of a lot of the real time interaction with things such as the ethernet and USB, freeing up the main processor from having to deal with the low level interactions with these. The linux drivers deal with all this already.

With the low power use of everything in the system it might be quite possible to run this as a battery powered device. It's not going to be very big either, something like 3x3 inches.

How does that sound, any thoughts?

Thanks,

John S.

Hi John - many thoughts on this....

1) Anything from an arm5 at 400Mhz or so would be enough for basic flac playback and possibly a limited display, but it would be infinitely preferable to have hardfloat support and armv6, single core would be ok (Pi type class - armv6 or later, 600MHz or more)
2) Floating point means better support of aac and vorbis and allows the standard libfaad, libvorbis to be used
3) Squeezlite has as small a footprint as I could manage, but it would be nice to have a bit more memory if we want to do hdmi user interface. [I have some thoughts in that area too - can you make it 128M at least?]
4) Can we validate it has real ehci usb hardware rather than the s*** that Pi has!)
5) Can we pick something which is arm based so libspotify will work on it?
6) Ability to run some form of server would be nice, long term this need not be LMS! However I think it would be good to have some headroom unless you think this hits the cost too much.

JJZolx
2013-01-24, 16:40
Some quick thinking and back of envelope figures comes up with the following:
...
How does that sound, any thoughts?

Headphone jack?

What about an IR receiver? It would be nice to be leave open the possibility of one day implementing a user interface, or at least having basic (if blind) player control. Plus the ability (with the headphone jack) to use IR Blaster.

I'm having a hard time seeing all those I/O connectors on a device that is 3" x 3". Something the size of an SB2 or larger would be fine with me. For sound quality, I would think the proximity of components on the board plays a role. Does cost go up much if that board is 3" x 6" or 4" x 8"?

JohnSwenson
2013-01-24, 17:48
Hi John - many thoughts on this....

1) Anything from an arm5 at 400Mhz or so would be enough for basic flac playback and possibly a limited display, but it would be infinitely preferable to have hardfloat support and armv6, single core would be ok (Pi type class - armv6 or later, 600MHz or more)
2) Floating point means better support of aac and vorbis and allows the standard libfaad, libvorbis to be used
3) Squeezlite has as small a footprint as I could manage, but it would be nice to have a bit more memory if we want to do hdmi user interface. [I have some thoughts in that area too - can you make it 128M at least?]
4) Can we validate it has real ehci usb hardware rather than the s*** that Pi has!)
5) Can we pick something which is arm based so libspotify will work on it?
6) Ability to run some form of server would be nice, long term this need not be LMS! However I think it would be good to have some headroom unless you think this hits the cost too much.

What I am thinking about is one of the TI cortex A8 CPUs, armV7 based with the VFPv3 floating point unit. The ones I'm looking at are in the 600-700MHz range. You can get faster ones but they cost more, and are only available on the bigger chips which are much harder to route, which most likely means a more expensive board.

The design I'm thinking of has 256MB memory, it's easy to go to 512MB but the memory chip costs 3 times as much for doubling the capacity. Anything above 512MB means multiple memory chips which again increases the board cost.

If you go up to 1GHz models you have to switch memory chip architecture which again costs more.

You can go up to 2.7GHz versions, but it's a HUGE chip that is going to take a pretty expensive board.

I'm thinking that the 600MHz version is more than enough for just a player. If we start adding a server at the same time we probably want at least the 1GHz version, it will be a bit more expensive though. Anything above 1GHz is going to cost a lot more. With a 1GHz processor and 512MB of memory it's probably in the $200 to $220 range for the board.

John S.

epoch1970
2013-01-24, 18:01
How does that sound, any thoughts?
VLAN support sounds great, and I suppose this means gigabit ethernet ? Then a single ethernet port would do for a router-on-a-stick configuration. Would save cost and power I guess.
In fact, I find VLAN extremely interesting. SBS setup, particularly networking/DNS seems a sore point for many. Over here in France we have an ISP called Free; they offer an internet gateway+a tv box; Plug both in your network -or via the provided CPL plugs- and automagically everything works: they use a specific VLAN to create the link between the 2, so the internet gateway can run a dhcp server and all services and QoS polcies needed, in its own realm. Nobody uses VLANs at home -except for VOIP perhaps, so what you get is a factory configured player-server pair, that works out-of-the box 99,99% times -and the 0.01% can understand why it's not working… True plug and play exists, I've seen it.

An NTP server would be nice, too.

I think a physical power button, and possibly physical rf-kill button would be pleasing.

If that thing is able to do room correction, does it make sense to have a mic in port for the device to figure out by itself what filter is needed ? (totally naive question; I've used once in my life an eq w/ pink noise generator.)

I too, vote for headphone/IR out, for IR Blasting. And IR receiver too. IR is fast, and simple.

And for a lot of headroom. If I had choice between $170 w/ 256MB ram and $190 w/ 1 or 2GB, I would not hesitate a second and choose the latter.
One of the beauties of the SB3 was its ability to improve over time, just with firmware upgrades. It was a thin device. If the new player is fat -and controlling the QoS would be one of the few good reasons- then I think we need a lot of free room -and power too. I keep my amps/speakers 10 years at least, the SB3 longevity was perfectly fit, and exemplary IMO.

Just my 2cts. With many thanks.

JackOfAll
2013-01-24, 18:42
I believe this to be very dac dependant - its useless for my dac, but others have not problems.. Its a great target if the usb can be made to work..

OK, well to quantify, I've yet to find a report of any UAC2 async implementation working well. By that I mean without any glitches at all. Sure, you can fiddle around with buffer sizes, but if USB packets are being dropped, which is what I believe is happening, it's game over. I have a gut feeling that it is not going to be fixed with a software update any time soon. I'm not holding my breath.

From my own point of view, I've tried just about every UAC2 capable chipset that exists with it. Even the reference XMOS design, with which I have not had a problem with any other piece of hardware on which I can compile and run the alsa usb driver. YMMV.

JackOfAll
2013-01-24, 18:59
I'm thinking that the 600MHz version is more than enough for just a player. If we start adding a server at the same time we probably want at least the 1GHz version, it will be a bit more expensive though. Anything above 1GHz is going to cost a lot more. With a 1GHz processor and 512MB of memory it's probably in the $200 to $220 range for the board.

John,

I'd encourage you to go for more rather than less. An A8 proc with at least 512M. (Pandaboard ES is A9 1.2GHz dual core with 1024MB RAM. That retails for $180.) I think there is a market for something that isn't bargain basement and that has the power to run more than just a software player. ie. the server as well. (That was supposed to be the Touch. But we all know what a dog that was for running the server.) If people want to do it at beer money prices, there are already ways of doing software players on the cheap with $30 devices and $20 USB DAC's. But if you are going to go to the trouble of designing a board, future proof it and build in flexibility, rather than it being just enough.

erland
2013-01-24, 23:44
I'm thinking that the 600MHz version is more than enough for just a player. If we start adding a server at the same time we probably want at least the 1GHz version, it will be a bit more expensive though. Anything above 1GHz is going to cost a lot more. With a 1GHz processor and 512MB of memory it's probably in the $200 to $220 range for the board.

If we are talking about a DIY model or a small volume module module pre-packaged for geeks, I would say that between:
- 600MHz + 256MB for $170
- 1GHz + 512MB for $220

I would go for the 1GHz model to make it more future proof. For a simple player we might not need the extra resources, but if we start adding HDMI support to able to connect it to a TV we might want to do visualization on the TV and show high res album covers and things like that could easily use more CPU and memory even if we don't run a server directly on the box.

Also, who knows, maybe we want to run Android on it sometime in the future to get access to the Android app market, in this case a bit more memory and faster CPU is probably also a good idea to make that kind of possibility an option.

The 2.7GHz model feels like way too much.

I don't think the price increase from $170 to $220 will cause a problem for DIY enthusiasts, the Raspberry Pi and SheevaPlug devices is attractive because they are below $100, if you go above $100 or $150 I don't think it matter much if its $150 or $250 for the DIY enthusiasts.

The situation would be a lot different if you are targeting mass market users, in this case the difference between a $170 and $220 board could be important.

Of course, if the board design will require a lot more work with a 1GHz model with 512MB, it might be better to do a first batch with the slower model to check the interest and upgrade it to a newer board later when there is a need. But in this case I would make the first model as simple as possible, to get it as cheap as possible and instead say that you will do a new design when there are needs for a faster CPU/more memory.

So basically it's a decision if you want the first version to be a bit future proof or just something that's works good with how we look at the world at this exact moment.

pssc
2013-01-25, 07:08
Yes, but the Pi onboard audio leaves more than a little to be desired from a SQ perspective. And as soon as you connect a UAC2 DAC you find out that the Pi is somewhat less than desirable as a platform in that regard, as well.

Yes the Pi has audio has issues and the PI foundation is investing in sorting this out and trying to sort the USB issues you can get stable audio via the right sort of USB DAC/sound card and when the ausio issues are sorted the HMI can feed an AV amp anyway... bear in mind we would have to buy a platform the was already supported by the linux kernel, I think it is easy to underestimate how difficult its all is to get working you can see that from the Pi and the issues there and it has substantial momentum which is important for projects such as this that and it will be around a bit longer than your standard package. If we try and to it all I think we are doomed to failure I suspect what we really want to do is moce forward the software platform that is squeezebox, so we cant take advantage of any suitable hardware.

Phill.

igoddard
2013-01-25, 07:37
What's the objective here? Just to provide replacement hardware for existing users or to grow the whole Squeezebox user-ship?

If the latter then I think you need to start with a self-contained appliance. I assume that everyone here is either running a server on the likes of an NAS, a commercial server, a self-built server (including me) or a desktop left switched on all the time. That isn't likely to be the profile of potential new users. A device that simply plays streams from a piece of kit the user doesn't have wouldn't make sense. If Logitech couldn't make money out of the product line I think the lack of a ready-made server must have been a factor.

What would make sense to a wider potential user-ship would be a box which looks like an existing piece of domestic electronics kit, allows existing CD collections to be ripped and stored, acts as a front end for on-line purchases, doesn't need mouse, keyboard or screen, allows web-management of the collection and plays the collection through existing audio kit. That would be a useful piece of kit in its own right and the potential to stream to other devices would be an add-on.

To some extent this sounds like the Vortexbox but in terms of a consumer device I think Fedora is probably the wrong base. Debian stable or a RHEL clone would be better. Or maybe even BSD. Also I'm not sure what tools Vortexbox provides for managing the collection. On my own server, because it runs headless, I use MPD plus an MPD web client that provides tag editing and another web application for file management, neither of which are as slick as I'd like nor are they integrated with each other or with the Squeezebox server. There's scope for extending the LMS or whatever it's called this week (the constant name changes can scarcely have helped sell the product) with such facilities.

eLR!C
2013-01-25, 07:41
Just a quick Pi based solution costing (tax / shipping excluded) of a wired SB3 style replacement :
- Pi B : 35$
- HiFiDIY Sabre USB DAC : 42 $
- 128 x 64 LCD Screen : 15$
- IR receiver : 3$
- Power : 10$
- few resistors, cables, solder, plugs, etc ... : 10$

TOTAL : 115$

Still miss a decent case, though ...

NB : Pi based because of its :
- linux / squeezelite support
- GPIO/SPI ports available
- python / C available libraries to interface screen and IR

dustinsterk
2013-01-25, 08:42
What I am thinking about is one of the TI cortex A8 CPUs, armV7 based with the VFPv3 floating point unit. The ones I'm looking at are in the 600-700MHz range. You can get faster ones but they cost more, and are only available on the bigger chips which are much harder to route, which most likely means a more expensive board.

The design I'm thinking of has 256MB memory, it's easy to go to 512MB but the memory chip costs 3 times as much for doubling the capacity. Anything above 512MB means multiple memory chips which again increases the board cost.

If you go up to 1GHz models you have to switch memory chip architecture which again costs more.

You can go up to 2.7GHz versions, but it's a HUGE chip that is going to take a pretty expensive board.

I'm thinking that the 600MHz version is more than enough for just a player. If we start adding a server at the same time we probably want at least the 1GHz version, it will be a bit more expensive though. Anything above 1GHz is going to cost a lot more. With a 1GHz processor and 512MB of memory it's probably in the $200 to $220 range for the board.

John S.

John,
Thank you for researching these items...this is very exciting! I am interested in the DAC and wireless chipset you have found. The ability to create its own network and possibly mesh multiple players is very interesting and really allows the product to be self contained without the need for additional equipment that an everyday user may or may not own. I think this feature alone could appeal to the masses. Allowing for the product to be truly plug and play is something that squeezebox fell very short on and it why I feel it never took off.

I would also agree that the additional cost for the 1GHz, 512MB is worth it. This would leave additional room for expansion to incorporate LMS (or some other server), etc. I also think that IR is important if we ever plan on utilizing the HDMI output for the display. The headphone jack, while not a must, maybe nice for some.

To Triode's point, we do need to validate it has real ehci usb hardware.

As far as a prototype of this board, how many would need to be ordered to start? Would there be an initial build fee, etc?

--Dustin

Julf
2013-01-25, 08:43
If the latter then I think you need to start with a self-contained appliance.

I think I have to disagree. The self-contained appliance has been tried a number of times, starting with the Rio Advanced Digital Audio Center (http://www.iapplianceweb.com/appreview/audio_players_27.htm) in 2001. All have been commercial failures.

Ripping CD's isn't going to be the dominating way to get your music into your server any more - downloading and streaming are more important, and in any case, you can't rip without keyboard and screen, as CDDB data isn't 100% perfect. So acquiring content is best done on a PC/Mac/whatever.

The server, with it's hard disk(s), is best placed away from your music system.

The players should be as small as possible, with no moving parts. And you want several of them.

So very conflicting requirements - not easily satisfied by a self-contained box.

JackOfAll
2013-01-25, 08:48
Yes the Pi has audio has issues and the PI foundation is investing in sorting this out and trying to sort the USB issues ....

On the 1/1/2013, there was a post over on the Pi forum from jamesh, (who is also a Broadcom employee), talking about the Pi's USB implementation. (ie. the Synopsys IP included on the Broadcom SoC.)


Yes, the Synopsis design is a bit pants. Broadcom didn't know that at the time. It's quite possible this is the first time this design has been used as a host - the client side works fine which is what is usually used in systems that use the design - so its entirely possible no-one has ever encountered the problems before. Now on to the legal stuff. Broadcom are NOT ALLOWED to distribute the RTL or the documentation for this design. It part of the legal contract between Broadcom and Synopsis drawn up when the design was bought. It would be good if they could, because there are indeed some decent engineers out there. But they cannot. This is the COMPLETELY standard approach to this - chip companies buy designs from others, and those designs are built in to chips. But most people never know that the chip they are using uses IP from many sources, because its all handled by the end supplier (in this case Broadcom).

On the basis that he is one of the few people that are privy to the IP and any documentation, (by virtue of being a Broadcom employee), and he describes it as being a "bit pants", I wont be holding my breath that we'll ever hear "perfect" audio from a UAC2 device driven from a Pi. Others, can come to their own conclusions. But I personally, wouldn't base any audio project where the requirement is for a decent USB out with which to use an external DAC, on the Pi.

JackOfAll
2013-01-25, 08:59
More as a reference to price than anything else..... I was going to buy one of these to have a fiddle with but never got around to it.

A13-OLinuXino (https://www.olimex.com/Products/OLinuXino/A13/A13-OLinuXino/)

A8 1GHz, 512MB RAM, for 45 EURO. Wi-Fi version (via a USB port) for an additional 10 EURO.

On-board USB hub is a GL850G

erland
2013-01-25, 09:26
What's the objective here? Just to provide replacement hardware for existing users or to grow the whole Squeezebox user-ship?

To be realistic, I think we are talking about a DIY system distributed to a limited number of DIY enthusiasts in the community.
It's not something that would have any significant impact of total number of Squeezebox users on short terms.
On longer terms the situation could be different, but then we are probably talking about a future revision of the hardware and not the one currently discussed.

P Nelson
2013-01-25, 10:02
I think the goal needs to be sorted out to provide guidance on this project. Yes, treat this like a project. I see several scenarios:
1) Build a box that relies on the existing Logitech software and mysqueezebox.com
a. A box for the tech savvy computer music enthusiast.
b. A box for a music enthusiastic, and if they follow very clear instructions with specific equipment and software, they can get it to work
c. Plug and play

2) New hardware and user interface (does not rely of Logitech’s software or servers)
a. A box for the tech savvy computer music enthusiast.
b. A box for a music enthusiastic, and if they follow very clear instructions with specific equipment and software, they can get it to work
c. Plug and play

If you are doing either 1a or 2a, I am not interested. In this thread I did not understand all this linux stuff, so I am not your audience. The instructions I have seen to upgrade/downgrade a UE radio make no sense to me!

If you are doing 1b., I am probably not interested as I already have a SB3, Touch, and two Radios. If it fixes the problems with the Touch to be a server, then I could be very interested if I think I could implement it successfully. If you are doing 2b, then I might be more interested to transfer to a platform that has a future.

The whole option 1 is puzzling to me because everyone here already has a SB product, so why do we need another self-made product? The answer is because it solves a problem with the existing SB line or it adds a feature that is currently not available. (Ok, some of you just want to tinker with DIY projects and that is the only reason you need.) For me, an enthusiast and not a computer geek, it needs to be implementable (with very clear and specific instructions) and reliable. However, I am concerned about investing more in a product when Logitech might pull the plug. My main use is to connect to my own music server, but I do like internet radio and the Pandora services, so I do want to use those services in the future.

If you are doing 1c, my comment is this is probably not a good idea as you might face the lawyers from Logitech and spending the effort to build a product that the manufacturer will no longer supports seems silly.

If you are doing 2c, then I could be interested. Especially if it WORKs without the buggy LMS software and other problems I am having with the Touch spontaneously shutting down. The Olive One looks like a promising replacement platform for the SB. If I order an Olive One, I will probably sell my 4 month old Touch to pay for it!

I met with the Olive One developer in their San Francisco office and I am intrigued. They are almost done with the hardware design. They are looking to add analog out, but it would require some board reconfigure. The user interface was about 40% done. I like the idea of the box being a server so I don’t need to turn the computer on or set another NAS device with is associated problems. They are also going to build a speaker that fits under the box. They are all very well made.

tcutting
2013-01-25, 10:30
I think I have to disagree. The self-contained appliance has been tried a number of times, starting with the Rio Advanced Digital Audio Center (http://www.iapplianceweb.com/appreview/audio_players_27.htm) in 2001. All have been commercial failures.

Ripping CD's isn't going to be the dominating way to get your music into your server any more - downloading and streaming are more important, and in any case, you can't rip without keyboard and screen, as CDDB data isn't 100% perfect. So acquiring content is best done on a PC/Mac/whatever.

The server, with it's hard disk(s), is best placed away from your music system.

The players should be as small as possible, with no moving parts. And you want several of them.

So very conflicting requirements - not easily satisfied by a self-contained box.

I agree with this point of view. The players should be kept somewhat simple. If someone is planning on a local music collection, surely they already have a PC which can perform the ripping.

erland
2013-01-25, 11:08
I think the goal needs to be sorted out to provide guidance on this project. Yes, treat this like a project. I see several scenarios:
1) Build a box that relies on the existing Logitech software and mysqueezebox.com
a. A box for the tech savvy computer music enthusiast.
b. A box for a music enthusiastic, and if they follow very clear instructions with specific equipment and software, they can get it to work
c. Plug and play

2) New hardware and user interface (does not rely of Logitech’s software or servers)
a. A box for the tech savvy computer music enthusiast.
b. A box for a music enthusiastic, and if they follow very clear instructions with specific equipment and software, they can get it to work
c. Plug and play

...

If you are doing 1c, my comment is this is probably not a good idea as you might face the lawyers from Logitech and spending the effort to build a product that the manufacturer will no longer supports seems silly.

To be realistic:
- Nobody targeting 1c or 2c would say so in public at this early stage, it would just create unnecessary high expectations among community members.
- Short term, 1a and maybe also 1b, is realistic.
- On longer terms things can change a lot, at the moment we are really just discussing the design of the circuit board, that board could on longer terms be put in a nice case, with or without built-in speakers, produced in big volumes and sold to the masses in normal stores.

So on longer terms something based on the current discussion could very well turn out to be 2c, but getting there is going to be a lot of work and its not just engineering work, so I suspect first 1a (and possibly 1b) and later 2a and 2b would have to be passed before trying reach 2c. However, depending on how the initial experiments turns out, the solution could very well also stay at 1a or 1b until the market comes up with something better. Also as you say, targeting 1c is going to be way too risky, at least if someone would want to sell it to the masses.

As I've said in other threads, I'm fairly sure some company on the market is going to reach 2c (with similar features as Squeezebox) and it's going to be interesting to see who gets there first. Unless someone have an urgent need to make a decision already now, I would suggest it's better to wait and see what happens during the next 6-12 months and then evaluate the situation again. We can always enjoy our Squeezeboxes and experiement with DIY solutions like the one discussed in this thread while we wait. I suspect we are going to see some interesting things happening during the next 6-12 months, maybe something in line with 2c (with similar features as Squeezebox) isn't as far away as some people think it is.

If someone is targeting 2c and want to provide similar features as Squeezebox, we are probably going to see the feature set start with a bit less features and be enhanced over time to eventually support all important features available on Squeezebox. I would personally keep my eyes open for solutions which seems to be open both on hardware and software side, that kind of solutions have the biggest chance to be enhanced over time, kind of similar to how Squeezeboxes have been enhanced through different kind of third party solutions, for example like the one discussed in this thread, Vortexbox, SqueezePlug and all the third party plugins/applets/apps available.

Triode
2013-01-25, 11:17
On the basis that he is one of the few people that are privy to the IP and any documentation, (by virtue of being a Broadcom employee), and he describes it as being a "bit pants", I wont be holding my breath that we'll ever hear "perfect" audio from a UAC2 device driven from a Pi. Others, can come to their own conclusions. But I personally, wouldn't base any audio project where the requirement is for a decent USB out with which to use an external DAC, on the Pi.

I tend to agree, but I was being generous to what they may achieve - I think implementing the missing ehci hardware scheduler in the graphics processor was being talked about at one point!! Having seen that usb support on devices is limited and even Touch and most arm chips don't have full transaction translators (hence need external hubs to support 1.1 devices), my belief is that we need to make sure whatever we target has full usb support in hardware and no closed source drivers!

Triode
2013-01-25, 11:22
What I am thinking about is one of the TI cortex A8 CPUs, armV7 based with the VFPv3 floating point unit. The ones I'm looking at are in the 600-700MHz range. You can get faster ones but they cost more, and are only available on the bigger chips which are much harder to route, which most likely means a more expensive board.

The design I'm thinking of has 256MB memory, it's easy to go to 512MB but the memory chip costs 3 times as much for doubling the capacity. Anything above 512MB means multiple memory chips which again increases the board cost.

If you go up to 1GHz models you have to switch memory chip architecture which again costs more.

You can go up to 2.7GHz versions, but it's a HUGE chip that is going to take a pretty expensive board.

I'm thinking that the 600MHz version is more than enough for just a player. If we start adding a server at the same time we probably want at least the 1GHz version, it will be a bit more expensive though. Anything above 1GHz is going to cost a lot more. With a 1GHz processor and 512MB of memory it's probably in the $200 to $220 range for the board.

John S.

This sounds good - can we validate the usb support. Must have ehci, most soc implementations I've tested need external TTs though for 1.1 support.

If we had 256M of memory then I think some form of custom UI for us is the way to go, rather than trying to run something bigger and use its scripting engine (I was looking at XBMC). I'm assuming you need to dedicate a portion of this to the graphics and I think we want enough for a 1080p display, but not for fancy rendering etc?

JJZolx
2013-01-25, 11:28
I'd be curious to know... Of all the people posting here with their gung ho enthusiasm for such a piece of equipment, how many will actually buy one or more at the expected price of (what are we up to now?) $300-$400? Personally, I have more Squeezeboxes than I know what to do with. I would have to think that nearly everyone else here does also. If I were to buy one, it would mostly be to play around with.

For this to be doable, even to have a run of, say, 100 units, it needs to be viable as a Squeezebox replacement that is usable by someone completely new to the Squeezebox ecosystem. Someone, who if they said "I've always wanted to try a Squeezebox, but I can't buy one", you could recommend without reservation that they purchase one of these devices rather than telling them to watch for a used Touch on ebay or Craigslist.

erland
2013-01-25, 11:50
I'd be curious to know... Of all the people posting here with their gung ho enthusiasm for such a piece of equipment, how many will actually buy one or more at the expected price of (what are we up to now?) $300-$400? Personally, I have more Squeezeboxes than I know what to do with. I would have to think that nearly everyone else here does also. If I were to buy one, it would mostly be to play around with.

For this to be doable, even to have a run of, say, 100 units, it needs to be viable as a Squeezebox replacement that is usable by someone completely new to the Squeezebox ecosystem. Someone, who if they said "I've always wanted to try a Squeezebox, but I can't buy one", you could recommend without reservation that they purchase one of these devices rather than telling them to watch for a used Touch on ebay or Craigslist.

I'm fairly sure there are 100 people on these forums who would be interested just because it's fun to do a DIY solution, there are a lot of geeks around here, some posting but also a lot who isn't active posters.

Selling it for $300-$400 to someone who is not a DIY geek and doesn't own a Squeezebox already is going to be hard.
I suspect you will be able to build it for less than $300, as I've understood it's just the case and power supply that's missing, but it will still be hard to sell it to someone who isn't owning a Squeezebox and isn't a DIY geek. They would prefer to get a used Squeezebox from eBay or just get a Sonos or one of the other alternatives available in their local store for similar price.

However, are we really targeting users who don't have a Squeezebox already ?
To me it feels like the initial target would be DIY geeks on these forums and possibly also some enthusiasts who aren't scared to try something new, all owning at least one Squeezebox already and loving the Squeezebox system and interested to try something new.

Mnyb
2013-01-25, 12:10
It is a good alpha/beta test of the "production line" :) can the community design build sell and distribute a product handle warranty provide documentation and help ? that in itself needs to be tested too .

So I would probably get a "community squeezebox mk1" just for the heck of it and test the thing .

JJZolx
2013-01-25, 12:19
Selling it for $300-$400 to someone who is not a DIY geek and doesn't own a Squeezebox already is going to be hard.
I suspect you will be able to build it for less than $300, as I've understood it's just the case and power supply that's missing, but it will still be hard to sell it to someone who isn't owning a Squeezebox and isn't a DIY geek. They would prefer to get a used Squeezebox from eBay or just get a Sonos or one of the other alternatives available in their local store for similar price.

Recommending someone buy something isn't quite the same thing as "selling" it.

From the discussion, we're not talking what I'd call DIY any more. If it relies on the existing LMS and its infrastructure, that part of the setup is no different than Squeezebox, and while installation and setup have never really been perfected, plenty of neophytes have gotten LMS up and running with little instruction. The device itself would be comparable to a Receiver, and with a web interface for network configuration, it could arguably be even easier to set up.


However, are we really targeting users who don't have a Squeezebox already ?

You keep using words like "targeting" and "sell".

Do you have commercial aspirations for this project?

erland
2013-01-25, 13:09
From the discussion, we're not talking what I'd call DIY any more. If it relies on the existing LMS and its infrastructure, that part of the setup is no different than Squeezebox, and while installation and setup have never really been perfected, plenty of neophytes have gotten LMS up and running with little instruction. The device itself would be comparable to a Receiver, and with a web interface for network configuration, it could arguably be even easier to set up.

With DIY I meant that each user would have to buy the parts and assemble it themselves and download and install the software, even if the software part would just be a matter of downloading an image and loading it to a SDHC card (or similar). This is all a big step compared to getting a Squeezebox Receiver in the store.

If someone would decide to sell it per-assembled and pre-installed they would end up with patent/licensing issues regarding MP3, WMA, AAC codecs as far as I've understood, since it would then be considered to be a end consumer device where these patents/licenses applies. Getting the necessary licenses would increase the price a bit more and would in worst case make it too expensive even for enthusiasts, especially if you can only sell it to 100 people where the MP3 license would add $150 to each device. Not sure if it would be possible to solve by letting the user install the codecs themselves, but that would make it even more complex to set it up and make it kind of a DIY device again.



You keep using words like "targeting" and "sell".

Do you have commercial aspirations for this project?

No, not at this time, but someone designing a new hardware needs to decide what type of users they will be able to recommend/convince to buy it. If you don't do this, you can easily end up in a scenario where you add a lot of features which the users buying it won't need or a scenario where it misses features which would be needed for people to buy it.

JJZolx
2013-01-25, 13:28
With DIY I meant that each user would have to buy the parts and assemble it themselves and download and install the software, even if the software part would just be a matter of downloading an image and loading it to a SDHC card (or similar). This is all a big step compared to getting a Squeezebox Receiver in the store.

We're talking about some kind of kit? Didn't sound like that to me from John's posts. If you're just talking about installing a board in a case, I'm game, but all that saves anyone packaging these things is a couple of minutes work. If you're talking about soldering RCA jacks and antenna leads, fuggedaboutit.


If someone would decide to sell it per-assembled and pre-installed they would end up with patent/licensing issues regarding MP3, WMA, AAC codecs as far as I've understood, since it would then be considered to be a end consumer device where these patents/licenses applies. Getting the necessary licenses would increase the price a bit more and would in worst case make it too expensive even for enthusiasts, especially if you can only sell it to 100 people where the MP3 license would add $150 to each device. Not sure if it would be possible to solve by letting the user install the codecs themselves, but that would make it even more complex to set it up and make it kind of a DIY device again.

I'd be interested in hearing other opinions about whether your concerns over pre-installing the necessary software are valid. I can see what you're saying about codecs, but the OS image itself? Wouldn't it be possible to automate the installation of the software necessary for the codecs from the planned web interface, possibly even making it part of the installation process itself? Scripts that would download and install the software, much like the extension downloader of LMS.

erland
2013-01-25, 14:06
We're talking about some kind of kit? Didn't sound like that to me from John's posts. If you're just talking about installing a board in a case, I'm game, but all that saves anyone packaging these things is a couple of minutes work. If you're talking about soldering RCA jacks and antenna leads, fuggedaboutit.

My guess is that it would be similar to a Raspberry Pi, basically you would just have to install the board in a case, no soldering should be needed unless I'm missing something.



I'd be interested in hearing other opinions about whether your concerns over pre-installing the necessary software are valid. I can see what you're saying about codecs, but the OS image itself? Wouldn't it be possible to automate the installation of the software necessary for the codecs from the planned web interface, possibly even making it part of the installation process itself? Scripts that would download and install the software, much like the extension downloader of LMS.

Agreed, would be good to get some information from someone who knows this stuff, I just read a bit yesterday and found the license prices here:
http://mp3licensing.com/royalty/hardware.html
(It's the minimum $15 000/year fee which is the issue)

I suspect you can't have it pre-installed on an image, I'm not sure if a way around it would to download and install it automatically during installation. Most application I've seen seem to instruct users to download and install mp3 decoders manually completely separate from the application, so that would definitely be an option, but it would make the installation process a bit more complex.

JackOfAll
2013-01-25, 14:43
Another point...... Going back to what John was saying about including a DAC chip with built-in OS/DF turned off and using FPGA (software) for OS/DF...... If that is part of the design, while using an external DAC would always be option, I suspect we're talking about Transporter (or better) analogue out SQ by default, not that of a $20 PCM270* eBay USB DAC. While that might not interest the mass market that is only interested in the best price possible, even if priced at $400, my feeling is that it will be cheap for what you are will be getting.

Mnyb
2013-01-25, 14:43
My guess is that it would be similar to a Raspberry Pi, basically you would just have to install the board in a case, no soldering should be needed unless I'm missing something.


Agreed, would be good to get some information from someone who knows this stuff, I just read a bit yesterday and found the license prices here:
http://mp3licensing.com/royalty/hardware.html
(It's the minimum $15 000/year fee which is the issue)

I suspect you can't have it pre-installed on an image, I'm not sure if a way around it would to download and install it automatically during installation. Most application I've seen seem to instruct users to download and install mp3 decoders manually completely separate from the application, so that would definitely be an option, but it would make the installation process a bit more complex.

Cant it just be a run once script that installs LAME or MAD or (insert decoder ) at the first convenient possibility . The it is at least technically the end user who is doing it .

Edit:_ maybe some charade is needed like a tic box "install third party decoders for better file compatibility " so that end user act's proactivly .

JohnSwenson
2013-01-25, 16:53
This sounds good - can we validate the usb support. Must have ehci, most soc implementations I've tested need external TTs though for 1.1 support.

If we had 256M of memory then I think some form of custom UI for us is the way to go, rather than trying to run something bigger and use its scripting engine (I was looking at XBMC). I'm assuming you need to dedicate a portion of this to the graphics and I think we want enough for a 1080p display, but not for fancy rendering etc?

I don't the answer, people are using EHCI and UAC (I don't know what flavor) without problems. The BeagleBone uses a processor from the same series and would probably be the easiest way to actually test the USB.

John S.

JohnSwenson
2013-01-25, 17:28
A couple thoughts: why would anybody want this board?
It has audio specific stuff on it you won't find on other general purpose computer boards, specifically an analog DAC output that is significantly better than what is on the Touch, you would have to get at least a $1000 USB DAC to get in this quality range. Very low jitter clocks (much lower than the ones in the Touch, but not as good as some of the best external DACs), a highly optimized S/PDIF coax output that is better than almost anything else out there no matter what the price. The beauty of this concept is that these extra "audiophile" options are easy and inexpensive to add when you are building them in from the ground up. It's when you take an existing general purpose system and try and add this as outboard "add-ons" that it gets quite expensive. I really want to do this with those extra options because that is what differentiates this from say a CuBox.

There ARE large initial setup fees for doing this, that is why I mentioned 25 units, at that price the amortization of the setup charge starts getting lower than the cost of the actual parts. Below that you can still do it, but the cost per board skyrockets.

What I am envisioning is a fairly simple first board, primarily designed to be a black box player, I would like to leave off the HDMI for the first board, it adds a significant amount of complexity. Designing this board will be fairly straight forward so something can be done and out there to a few developers quite quickly. I did some more checking and found out that the 1GHz processor is actually easier to layout than the 600MHz one, they did a much better job of optimizing the ball layout. The interesting thing is that the price in small quantities is almost identical. So I'll just go with the 1GHz processor. We have a choice of 256MB or 512MB and keep it with a single chip. The 512MB one costs $20 more and is significantly more work in the layout. (the board won't cost more, but it will take longer to get layed out) Because of the more layout effort I'm thinking it might be a good idea to go with the 256MB for the first board.

Once these boards are out the software types can get a working linux distribution with Squeezelite handling the SB part. The idea is that the firmware is one file that gets written to an SD card which when booted by the board has it up and running as a black box receiver. Until that point it WILL be a geek fest to get it working, but because the mission is simple (black box receiver) it hopefully will not take too long to get a firmware file up and running.

This process gives a working board that does not need a full blown geek to get working (plug in the SD-card, turn it on), at that point we have something that might appeal to more people and we can start looking at industrial design and options for a more flexible board (display outputs, running server etc), but I think its a good idea to start with a very simple one first to get bugs ironed out and find out what it is capable of doing.

John S.

JackOfAll
2013-01-25, 17:50
I really want to do this with those extra options because that is what differentiates this from say a CuBox.

COAX, USB and a decent DAC onboard. Would you still do the OS/DF in FPGA? I guess this is really pushing my luck, but any chance of an I2S output?


There ARE large initial setup fees for doing this, that is why I mentioned 25 units, at that price the amortization of the setup charge starts getting lower than the cost of the actual parts. Below that you can still do it, but the cost per board skyrockets.

I don't think you would have any problem getting up-front commitments for 25 units.


The 512MB one costs $20 more and is significantly more work in the layout. (the board won't cost more, but it will take longer to get layed out) Because of the more layout effort I'm thinking it might be a good idea to go with the 256MB for the first board.

I really do think you should shoot for 512MB from the off, even if add adds time to delivery because of the increased layout complexity.


Once these boards are out the software types can get a working linux distribution with Squeezelite handling the SB part. The idea is that the firmware is one file that gets written to an SD card which when booted by the board has it up and running as a black box receiver. Until that point it WILL be a geek fest to get it working, but because the mission is simple (black box receiver) it hopefully will not take too long to get a firmware file up and running.

A days work! ;)

erland
2013-01-25, 20:28
What I am envisioning is a fairly simple first board, primarily designed to be a black box player, I would like to leave off the HDMI for the first board, it adds a significant amount of complexity. Designing this board will be fairly straight forward so something can be done and out there to a few developers quite quickly.

...

This process gives a working board that does not need a full blown geek to get working (plug in the SD-card, turn it on), at that point we have something that might appeal to more people and we can start looking at industrial design and options for a more flexible board (display outputs, running server etc), but I think its a good idea to start with a very simple one first to get bugs ironed out and find out what it is capable of doing.

So, if I understand you correctly, what you are basically saying is:
1. Iteration 1: Create a batch of 25 boards to the most interesting people around here, preferably the group would be a mix of audiophiles, software developers and DIY enthusiasts.
2. Let them experiment a bit and implement/package the software for it.
3. Iteration 2: Review the experimentation, re-design what's needed to make it future proof and design a new board that could be produced for a bit more people, possibly even pre-packaged in a case with pre-installed software.

In this scenario, my priorities would be to make something as fast as possible in iteration 1, as long as you are reasonably sure that:
- The changes in iteration 2 will still work with the software written for iteration 1
- The changes in iteration 2 will result in similar or better audio characteristics compared to iteration 1

In my mind, it's important that we can use the experimentation of iteration 1 board to improve the board in iteration 2.

Top notch audio quality and making it future proof is not important in iteration 1, it will be a temporary solution and you just need something that's good enough to allow the experimentation needed to evolve it to the iteration 2 board.

CPU and memory isn't important in iteration 1 as long as you feel that you are prepared to improve both of them in iteration 1. You are not going to want to improve it because of the experimentation on iteration 1 board, you are going to want to improve it to make room for future software improvements which will happen after iteration 2 board has been released.

For iteration 1 board, you could safely go with a 600MHz CPU and 128MB memory if you like, as long as you are prepared to change it to 1GHz+ and 512MB+ in iteration 2 to make it more future proof when you add the HDMI output. For iteration 1 (without HDMI output), 600MHz and 128MB will be plenty, nobody is going to do something that requires more than that during experimentation on iteration 1 board. The faster CPU and more memory is needed for things that might happen months after the iteration 2 board has been released. The people signing up for iteration 1 board will likely have no problem to also sign up for iteration 2 board, but the people who only sign up for iteration 2 board is going to expect something that works on longer terms, they don't want to hear that an improved iteration 3 board revision is available 3 months after they purchased the iteration 2 board, at least not unless you explicitly also say that iteration 2 is a temporary board for further experimentation.

For iteration 1 board, I'm not sure you even need the built-in DAC if that delays iteration 1 or makes it more expensive, because from a software perspective iteration 1 will focus on developers who try to experiment how to get the software to work properly with USB DAC's and S/PDIF connected amplifiers. If you feel the DAC part needs some experimentation by the 25 developers/audiophiles, and you put it on a separate board, you can maybe even first design and release the main board and then a bit later design and release the DAC sub board. You can even choose to skip the S/PDIF in the iteration 1 board, but doing that might result in that you might get a harder time to find 25 people with development experience to participate, some people who are developers and would be willing to test iteration 1 probably don't own a good USB DAC today and isn't prepared to buy a good USB DAC as a temporary solution just to try iteration 1 board.

As I look at it, the parts that can result in significant more memory/CPU needed in the future is:
- HDMI output: People are going to want to show a lot of cool things on the TV and this will require more CPU and memory, since the HDMI output isn't part of iteration 1, you won't see the needs during experimentation, so you have to guess a bit what's needed. Obvious use cases that people are going to request to be able to show through HDMI output are hires album art, VU meters/visualization and maybe even video. I know video is to ask a bit much, but you are definitely going to get requests for that if you add a HDMI output because people are going to start thinking about AirPlay support pretty soon.
- Audio processing like room correction, equalizer and similar things: Most of this could maybe be handled by the DSP and not affect the CPU much, but if the CPU is involved it could require a faster CPU and possibly also more memory.
- Built in server: This is going to require both more memory and faster CPU, but based on what I know I'm not convinced this is what we should design for. It really doesn't make sense to design the hardware to run LMS in each individual player, if we want a solution without a computer we probably want a solution which doesn't rely on LMS and then the server part (if needed at all) can be designed a lot more lightweight than LMS is today. Whatever we do, we don't want to repeat Logitech's mistake and try to run LMS on a device which doesn't have the necessary resources, that will just result in disappointed users and a lot of complaints.

JJZolx
2013-01-25, 20:57
As the design and the board progresses, would it eventually have onboard flash memory, or is it always envisioned as loading from an SD card?

JohnSwenson
2013-01-26, 01:50
There should be no soldering needed to make the board useful. The wifi is a mini-PCIe form factor, it just pushes into the socket. You DO have to plug in an antenna of some sort, its a standard UFL jack on the module.

All the other connectors are on the board, putting it in the case is just putting it in place so the connectors go through the holes and either screwing the board in or pushing down onto some of those nylon hold downs.

I really want to put the DAC on the GEN1 board. It's a new design I haven't used before and I want to have a platform to play around with the internal DSP. I want to find out how good we can make this sound.

Someone else brought up an interesting aspect, if the DSP is done in the DAC, it can't be applied to the S/PDIF or USB. For just straight playback, that won't matter since the only thing I will be doing with at least at first is the interpolation filter, which is already included in any external DAC. For long term GEN2 it might be best to have the FPGA DSP based system, then you can do anything you want and it will be useful for all outputs. But that is definitely NOT going to be in GEN1.

I did some more poking around the processor/memory issues, it's a bit more complicated than I thought at first. It looks like the best bet for GEN1 is a 720MHz processor and 256MB RAM. This does not have TDMI interface, it does have an LCD interface. For GEN2 a 1GHz processor and 512MB RAM, this comes with a full blown video controller and built in HDMI and VGA interface. No need for external chips, just hook up connectors. The GEN1 is a much simpler board layout task so I would like to go with it. I COULD do the faster processor from the get-go, put its more work and costs a little more (about $10 more for the board, about $15 more for the processor and $20 more for the memory).

I actually did a full quote on board costs and its actually right around what I thought, the board and assembly for a GEN1 will be $64 for 25, The GEN2 is about $75. So the rest of the cost is the parts which look like around $90 to $100 for a Gen 1. So that hits the $170 for the board. It's $35 for the wifi module which you can add at any time. The place I'm working with does the parts procurement as well, so it's just send files and money and a couple weeks later get a box of fully assembled boards.

The Gen1 board will have no display, so all development has to be over ssh or serial port. I'll probably put a serial port on it so you can have a hardware console during boot.

So it looks like it will have an ethernet jack, 2 USB-A jacks, serial jack, S/PDIF coax, 2 RCA jacks, SD card (probably a micro), power jack, socket for Wifi module. Anything else I need in there?

The big question is, should it have a headphone jack. The easy, inexpensive headphone circuits are not all that great and add more complexity to the board. I know how to make a REALLY good headphone amp, but it will add quite a bit of complexity to the board and some extra cost. So what are your thoughts:
1; no headphone jack
2; simple, cheap, not so great
3; whole hog really good, but complex and pricy.

Also should it have a TOSLINK?

John S.

eLR!C
2013-01-26, 02:13
That sounds really great : the specs you propose (i.e. included DAC and defaut jacks) and the related price make sense to me .
I personnaly don't need the TOSLINK and depending on complexity, an IR receiver could be great (as I found it great that with SB3 you don't need to power your phone or computer to do play / pause / modify volume)

As far as the headphone is concerned, a cheap jack could be useful for debugging the interface during night development but is not mandatory

(btw, count me in)

JJZolx
2013-01-26, 02:14
I'd vote simple, cheap headphone jack.

Would most connectors be on just the rear edge of the board? Not important on the first go 'round, but I think it's important, rather than having a player with connectors and cables coming off of several sides. The headphone jack and SD card slots could be on the side.

Power switch? Not needed on the first generation, but would be high on my wishlist.

Is it possible to design a box that could completely power down the wifi radio when it's not in use, perhaps even by an external switch if necessary?

What sampling rates would this Squeezebox ultimately be capable of?

JJZolx
2013-01-26, 02:18
BTW, John... Where are you located? Perhaps we can find someone nearby to help you with shipping and some of the other logistics of distributing the boards.

erland
2013-01-26, 02:20
I really want to put the DAC on the GEN1 board. It's a new design I haven't used before and I want to have a platform to play around with the internal DSP. I want to find out how good we can make this sound.

Ok, then it makes sense.
I'm definitely willing to pay for it just to make it possible for you to experiment with it so we can get something really great in GEN2.



I did some more poking around the processor/memory issues, it's a bit more complicated than I thought at first. It looks like the best bet for GEN1 is a 720MHz processor and 256MB RAM. This does not have TDMI interface, it does have an LCD interface. For GEN2 a 1GHz processor and 512MB RAM, this comes with a full blown video controller and built in HDMI and VGA interface. No need for external chips, just hook up connectors. The GEN1 is a much simpler board layout task so I would like to go with it. I COULD do the faster processor from the get-go, put its more work and costs a little more (about $10 more for the board, about $15 more for the processor and $20 more for the memory).

I would go with the slower CPU and less memory for GEN1, since GEN1 is just a temporary experimentation platform to get to GEN2 it doesn't make sense that people should have to pay for the more expensive CPU/memory both in GEN1 and GEN2. For GEN2 I definitely want the faster CPU/memory to make it more future proof.



So it looks like it will have an ethernet jack, 2 USB-A jacks, serial jack, S/PDIF coax, 2 RCA jacks, SD card (probably a micro), power jack, socket for Wifi module. Anything else I need in there?

For GEN2, some kind of line-in would be nice if you believe GEN2 in the future could be packaged in a case with built-in speakers, the line-in on the Squeezebox Boom can be really useful if you want to use it as a speaker for external sources like a smart phone or similar device. If you think a product with built-in speakers would require a completely different board, a line-in doesn't make sense at this stage.

IR and HDMI would also be of interest for GEN2, but that has already been mentioned earlier.



The big question is, should it have a headphone jack. The easy, inexpensive headphone circuits are not all that great and add more complexity to the board. I know how to make a REALLY good headphone amp, but it will add quite a bit of complexity to the board and some extra cost. So what are your thoughts:
1; no headphone jack
2; simple, cheap, not so great
3; whole hog really good, but complex and pricy.

For GEN1 it isn't needed at all.
For GEN2 something with similar audio quality as the Squeezeboxes is probably a good idea.



Also should it have a TOSLINK?

In my opinion the S/PDIF is enough.
However, if you can add the TOSLINK without adding a lot of complexity or cost, having both TOSLINK and S/PDIF in GEN2 could be nice for people who only have free TOSLINK connections in their DACs/Amplifiers.

Triode
2013-01-26, 02:34
As the design and the board progresses, would it eventually have onboard flash memory, or is it always envisioned as loading from an SD card?

I think keeping all the flash on a card (micros SD) is probably best as it makes it easy to avoid the "bricking" scenario - asking someone to remove the card and reflash it from a PC is much easier than the debricking process we have with touch or the non existant debrick on radio... For a community project there will be much less QA so there is a risk of this...

Triode
2013-01-26, 02:40
There should be no soldering needed to make the board useful. The wifi is a mini-PCIe form factor, it just pushes into the socket. You DO have to plug in an antenna of some sort, its a standard UFL jack on the module.

All the other connectors are on the board, putting it in the case is just putting it in place so the connectors go through the holes and either screwing the board in or pushing down onto some of those nylon hold downs.

I really want to put the DAC on the GEN1 board. It's a new design I haven't used before and I want to have a platform to play around with the internal DSP. I want to find out how good we can make this sound.

Someone else brought up an interesting aspect, if the DSP is done in the DAC, it can't be applied to the S/PDIF or USB. For just straight playback, that won't matter since the only thing I will be doing with at least at first is the interpolation filter, which is already included in any external DAC. For long term GEN2 it might be best to have the FPGA DSP based system, then you can do anything you want and it will be useful for all outputs. But that is definitely NOT going to be in GEN1.

I did some more poking around the processor/memory issues, it's a bit more complicated than I thought at first. It looks like the best bet for GEN1 is a 720MHz processor and 256MB RAM. This does not have TDMI interface, it does have an LCD interface. For GEN2 a 1GHz processor and 512MB RAM, this comes with a full blown video controller and built in HDMI and VGA interface. No need for external chips, just hook up connectors. The GEN1 is a much simpler board layout task so I would like to go with it. I COULD do the faster processor from the get-go, put its more work and costs a little more (about $10 more for the board, about $15 more for the processor and $20 more for the memory).

I actually did a full quote on board costs and its actually right around what I thought, the board and assembly for a GEN1 will be $64 for 25, The GEN2 is about $75. So the rest of the cost is the parts which look like around $90 to $100 for a Gen 1. So that hits the $170 for the board. It's $35 for the wifi module which you can add at any time. The place I'm working with does the parts procurement as well, so it's just send files and money and a couple weeks later get a box of fully assembled boards.

The Gen1 board will have no display, so all development has to be over ssh or serial port. I'll probably put a serial port on it so you can have a hardware console during boot.

So it looks like it will have an ethernet jack, 2 USB-A jacks, serial jack, S/PDIF coax, 2 RCA jacks, SD card (probably a micro), power jack, socket for Wifi module. Anything else I need in there?

The big question is, should it have a headphone jack. The easy, inexpensive headphone circuits are not all that great and add more complexity to the board. I know how to make a REALLY good headphone amp, but it will add quite a bit of complexity to the board and some extra cost. So what are your thoughts:
1; no headphone jack
2; simple, cheap, not so great
3; whole hog really good, but complex and pricy.

Also should it have a TOSLINK?

John S.

Sounding great to me John. Few questions:

1) Do we need Wifi could a usb dongle be used at lower cost?
2) Assume we keep all flash on the SD/microSD to avoid the bricking case (see above case)
3) Are both usb ports on an internal hub or are they separate controllers on the processor
4) can you point me at the datasheet for the processor you are planning on?

chill
2013-01-26, 02:40
A couple thoughts: why would anybody want this board?
It has audio specific stuff on it you won't find on other general purpose computer boards, specifically an analog DAC output that is significantly better than what is on the Touch, you would have to get at least a $1000 USB DAC to get in this quality range. Very low jitter clocks (much lower than the ones in the Touch, but not as good as some of the best external DACs), a highly optimized S/PDIF coax output that is better than almost anything else out there no matter what the price. The beauty of this concept is that these extra "audiophile" options are easy and inexpensive to add when you are building them in from the ground up. It's when you take an existing general purpose system and try and add this as outboard "add-ons" that it gets quite expensive. I really want to do this with those extra options because that is what differentiates this from say a CuBox.


These are indeed the reasons that this product will stand out. Audiophile performance on a DIY budget. Even if the rest of the world remains unconvinced about Squeezebox and prefers their Sonos or Airplay systems, in this community we know the value of the Squeezebox ecosystem, and whilst off-the-shelf hardware is already filling some of the player gap, I think a player whose design focus from the outset is very high SQ will go like hot cakes in this community. I'd also hope that the power supply part will conform to John's very high standards in this area.

I'm no software developer, I've already got all the Squeezeboxes I need (and a spare Touch in the loft) but I still want in on one of the first batch of 'our' player. I might use it to replace the currently dormant SB2 that I built into my DIY preamp a couple of years ago. Any chance of a balanced output as well as RCA?

igoddard
2013-01-26, 05:43
(Numbering added by IG)
1 Ripping CD's isn't going to be the dominating way to get your music into your server any more - downloading and streaming are more important, and in any case, you can't rip without keyboard and screen, as CDDB data isn't 100% perfect. So acquiring content is best done on a PC/Mac/whatever.

2 The server, with it's hard disk(s), is best placed away from your music system.

3 The players ... you want several of them.



1. Irrespective of whether you rip or download at some point you need to (a) get the track registered with the database and (b) amend the meta-data (a lot of my music is classical so, believe, me, I know all about the inadequacies of CDDB-acquired meta-data!). So at present you do that on a "PC/Mac/whatever" and then, as a separate process, run a scanner to perform the data-acquisition in bulk, periodically rescanning and, as people with large collections complain about, waiting for that to happen. If you decide your metadata isn't right, edit it, rescan & wait. Why?

Wouldn't it be better to have the rip/download functionality aware of the server D/B update it with each rip or download as it works? And wouldn't it be at least as effective to amend the D/B's version of the acquired metadata via the server's web interface and, if you wanted, then amend the embedded metadata in the track from that?

2. Why?

3. You only need players once you've got something to stream, unless you're relying entirely on streaming from the internet.

FWIW I have a headless server built into one of the old Hiper cases which, sadly, are no longer made & getting rarer on eBay. This box was built to the dimensions & finish of a typical domestic audio or video appliance. I've fitted a fanless mini-ITX board & lap-top optical & hard drives. Sitting inside the cabinet with the rest of my kit it's inaudible. It's also headless. It can rip CDs automatically and management is done by web interfaces; the keyboard and screen are needed but they're just not directly attached to the server after initial setup. The latter isn't perfect because it isn't integrated with the LMS database.

If the acquisition. metadata editing and file shuffling facilities were integrated with the server there'd be no need to have the latter scan anything unless I wanted a precaution against my logging in via SSH & moving things round behind the server's back but this could be handled by some sort of stock-taking scan could be backgrounded.

toby10
2013-01-26, 06:12
2. noise, clutter, no interest in having a computer in the room (which is a big selling point for "networked" audio)

3. same as #2, many do not want/need/desire a big *box* in our AV rack or even in the same room

IMO, keep the computer, server, storage, files, etc... completely away from my living room. I just need/want a player at my listening area. I already have several computers to rip & store music, I don't need another. :)

garym
2013-01-26, 06:19
2. noise, clutter, no interest in having a computer in the room (which is a big selling point for "networked" audio)

3. same as #2, many do not want/need/desire a big *box* in our AV rack or even in the same room

IMO, keep the computer, server, storage, files, etc... completely away from my living room. I just need/want a player at my listening area. I already have several computers to rip & store music, I don't need another. :)

+1. That's why I use a headless server ( vortexbox) located in a back room closet. But *if* I wanted a ripper, file server, and player all in one box, the vortexbox already does all this.

Edit: but I'd definitely be interested in a player with a John Swenson designed DAC.

Mnyb
2013-01-26, 07:04
+1. That's why I use a headless server ( vortexbox) located in a back room closet. But *if* I wanted a ripper, file server, and player all in one box, the vortexbox already does all this.

Edit: but I'd definitely be interested in a player with a John Swenson designed DAC.

+1 why on earth would I want a server in the hifi rack , my server resides under my desk in another room .

I'm on to for a player as guniea pig :) I'm quite tolerant re awkward setups and bugs .and I can follow instructions read electrical drawings and assemble stuff ,solder skills are a bit rusty never tried SMD components ,but solder some cables and put the thing in a box , no problem at all. I have an mobile esd kit so I would not have problems with components sensitive to static .
( I used to repair frequency converters and DC drives for a living ).

It could run it as digital transport or analog in the kitchen or if a hdmi implementation is ready I could try out hdmi .

dyohn
2013-01-26, 08:35
If it's for fun, go ahead and recreate the wheel. But I say once more, the VAMP with a good USB DAC does exactly what this thread seems to want, with the exception of IR control (but why you'd even want that since it is IP controlled, I don't know) and does it for a lot less money than is being talked about.

JohnSwenson
2013-01-26, 14:10
Sounding great to me John. Few questions:

1) Do we need Wifi could a usb dongle be used at lower cost?
2) Assume we keep all flash on the SD/microSD to avoid the bricking case (see above case)
3) Are both usb ports on an internal hub or are they separate controllers on the processor
4) can you point me at the datasheet for the processor you are planning on?

I like the concept of the wifi module connecting via ethernet. The processor chip has two ethernet ports on an internal switch, the idea is that one goes to the outside world and the other goes to the wifi. As far as the processor and software is concerned the wifi is just another device on the network. You literally don't have to care whether something is coming from wired or wifi. The software just has to worry about a single ethernet connection. Any wifi setup issues are dealt with by browsing to the wifi web page, either through the wifi or wired port, so the firmware on the processor doesn't have to know anything about it. I just think it makes things so much simpler from a software perspective. Since I am thinking about configuration of the player be controlled by an internal web server, this can just link to the wifi module's web page. Since it is connected through a hardware switch, you can always get to the wifi configuration via a hardwired connection to the player.

Each USB port has it's own separate controller, each of which can either be a device or host.

The processor is a TI AM3358, the technical reference manual gives a lot of detail on the USB subsystem:
http://www.ti.com/lit/ug/spruh73g/spruh73g.pdf

John S.

Triode
2013-01-26, 15:14
The processor is a TI AM3358, the technical reference manual gives a lot of detail on the USB subsystem:
http://www.ti.com/lit/ug/spruh73g/spruh73g.pdf

John S.

Its worth us looking into the usb subsystem seeing as it seems to be differnet from the ones I know work - its not ehci based from what I can see. I don't want us to have a Pi disaster on the usb ports... What we need to look for is positive use cases of linux iso code working with the musb usb controller.

Edit: is this the same chip John: https://github.com/RobertCNelson/linux-dev/issues/2 ?? (slightly worried by that..)

JackOfAll
2013-01-26, 16:09
Edit: is this the same chip John: https://github.com/RobertCNelson/linux-dev/issues/2 ?? (slightly worried by that..)

When I was asking around after I couldn't get the Pi working properly with UAC2, the BeagleBone was a device I was told to stay away from.

JJZolx
2013-01-26, 16:12
It's nice to be able to go back to the drawing board before you even begin drawing.

JackOfAll
2013-01-26, 16:33
When I was asking around after I couldn't get the Pi working properly with UAC2, the BeagleBone was a device I was told to stay away from.

Following up my own post. Bad form, I know. I was also told by the same person that I wouldn't have a problem with either the BeagleBoard XM or the Pandaboard. Neither of which I have tried myself. Both of these use a USB3320 PHY for the host hub.

Triode
2013-01-26, 16:46
Following up my own post. Bad form, I know. I was also told by the same person that I wouldn't have a problem with either the BeagleBoard XM or the Pandaboard. Neither of which I have tried myself. Both of these use a USB3320 PHY for the host hub.

The XM looks to have a AM3715 which has a dedicated usb host port using ehci - which would be preferable. (though I'm not saying we shoudl use this, just that I think a host only port using ehci is possibly preferable)

JohnSwenson
2013-01-26, 23:08
The XM looks to have a AM3715 which has a dedicated usb host port using ehci - which would be preferable. (though I'm not saying we shoudl use this, just that I think a host only port using ehci is possibly preferable)

I've spent all afternoon looking at this, what I can come up with is that the USB ports on the Am3358 are EHCI compatible when used in host mode. (hardware pins forcing host mode). There is a driver that works for this (OMAP_ehci). The problem seems to be with the musb driver which is the one specifically written to handle the OTG modes, which is what the kernels use since they detect what it actually is. This may be wrong since I haven't actually found anybody outright saying this, but from reading between the lines this is what seems to be happening. If this is true it might be possible to force the use of the ehci driver rather than the musb driver.

There have also been reports that these issues only occur with newer kernels and that things were working with older kernels.

The AM3715 was one of my top contenders, but it does not support DDR2 or DDR3 memory, only LPDDR, which has a memory speed about half of what you can get from DDR2. The memory chips are also quite a bit more expensive and larger than regular DDR2 memory chips.

I've ordered a BeagleBone, it should be here this coming week sometime and I can actually play with it and actually see what happens with different kernels and DACs.

John S.

Triode
2013-01-27, 04:16
I've spent all afternoon looking at this, what I can come up with is that the USB ports on the Am3358 are EHCI compatible when used in host mode. (hardware pins forcing host mode). There is a driver that works for this (OMAP_ehci). The problem seems to be with the musb driver which is the one specifically written to handle the OTG modes, which is what the kernels use since they detect what it actually is. This may be wrong since I haven't actually found anybody outright saying this, but from reading between the lines this is what seems to be happening. If this is true it might be possible to force the use of the ehci driver rather than the musb driver.

There have also been reports that these issues only occur with newer kernels and that things were working with older kernels.

The AM3715 was one of my top contenders, but it does not support DDR2 or DDR3 memory, only LPDDR, which has a memory speed about half of what you can get from DDR2. The memory chips are also quite a bit more expensive and larger than regular DDR2 memory chips.

I've ordered a BeagleBone, it should be here this coming week sometime and I can actually play with it and actually see what happens with different kernels and DACs.

Great - let us know where you get to. My only waryness with this is that we don't want to get into needing to look at linux usb drivers, so I would prefer to be using the ones commonly used and know to be working. The Pi uses something which appears not to have a hardware scheduler and relies on the interrupt driver to schedule packets - which leads to it missing packets in iso streams... The EHCI principle of having a hardware schedule is working well for us on other devices so is lowest risk... (Plus I spend too long instrumenting the EHCI scheduler to reach the conclusion of what Touch hardware would do :))

Freddy
2013-01-27, 05:40
This sounds really interesting and count me in for a box if it becomes reality.
It would be nice if a new box could integrate with the old SB-devices.

Couldn't something like this be founded using Kickstarter or similar?

servies
2013-01-27, 06:52
Cant it just be a run once script that installs LAME or MAD or (insert decoder ) at the first convenient possibility . The it is at least technically the end user who is doing it .

Edit:_ maybe some charade is needed like a tic box "install third party decoders for better file compatibility " so that end user act's proactivly .
This is the way to get rid of those mp3 license issues.
Every large Linux distribution works the same way.
But you need someone to provide the Lame build and preferrably this build is not being done by someone directly connected to this project.
And if the first real product coming from this is after 2017 we don't have to worry about those mp3 licenses anyway...

reinholdk
2013-01-27, 13:55
I have the feeling that creating a squeezebox replacement with a sound quality even better than the Touch - as worked out by John - would attract the most people. That would be a true value proposition over other devices, at least over those that can be used as a squeezebox device.

Simply doing yet another squeezebox would attract only people who need either a replacement if their existing squeezebox dies or who need just one more squeezebox - both groups are probably limited and decrease over time when other systems gain more interest.

JohnSwenson
2013-01-27, 15:13
Great - let us know where you get to. My only waryness with this is that we don't want to get into needing to look at linux usb drivers, so I would prefer to be using the ones commonly used and know to be working. The Pi uses something which appears not to have a hardware scheduler and relies on the interrupt driver to schedule packets - which leads to it missing packets in iso streams... The EHCI principle of having a hardware schedule is working well for us on other devices so is lowest risk... (Plus I spend too long instrumenting the EHCI scheduler to reach the conclusion of what Touch hardware would do :))

I found out that the recent kernels have a config option that lets you choose whether you want to use musb or ehci with the TI processors. Since the BeagleBone uses one port in host mode and one in device mode it has to enable the musb driver. Once I get mine in I'm going to try compiling the kernel with just the ehci driver and see if that works.

The config also has two TT modes so I can try those out and see if they make any difference.

The problem people seem to have happening is that the musb implementation of the DMA subsystem is not working, forcing them to switch to PIO mode, which when the processor gets busy causes problems. (it seems to be fine as long as the processor is not busy)

I have also seen messages of a patch designed to fix the DMA issue with the musb, so the issue may be fixed already.

So it looks like we will not need to hack the driver code, just make sure we use the RIGHT one.


I'll let you know if I'm having any problems with figuring out the correct config settings.

John S.

Triode
2013-01-27, 16:16
I've spent all afternoon looking at this, what I can come up with is that the USB ports on the Am3358 are EHCI compatible when used in host mode. (hardware pins forcing host mode). There is a driver that works for this (OMAP_ehci). The problem seems to be with the musb driver which is the one specifically written to handle the OTG modes, which is what the kernels use since they detect what it actually is. This may be wrong since I haven't actually found anybody outright saying this, but from reading between the lines this is what seems to be happening. If this is true it might be possible to force the use of the ehci driver rather than the musb driver.

Just read through the usb section of the data sheet again - it doesn't seem to be the same as EHCI, but lets hope it works... EHCI keeps a schedule of the next several frames worth of transactions in a shared memory block and doesn't require interrupts per packet/frame - it looks like this does.. [In contrast the AM37x technical reference manual includes all the details of EHCI and register maps I would expect - there's definitely a difference between it and the AM335x from the data sheet.]

Lets keep our fingers crossed! Could you test full speed and high speed devices. There is no mention of split transactions in the datasheet, so I wonder how TT works - perhaps if we only have support for native full speed or native high speed this does not matter.

dustinsterk
2013-01-28, 08:37
There should be no soldering needed to make the board useful. The wifi is a mini-PCIe form factor, it just pushes into the socket. You DO have to plug in an antenna of some sort, its a standard UFL jack on the module.

All the other connectors are on the board, putting it in the case is just putting it in place so the connectors go through the holes and either screwing the board in or pushing down onto some of those nylon hold downs.

I really want to put the DAC on the GEN1 board. It's a new design I haven't used before and I want to have a platform to play around with the internal DSP. I want to find out how good we can make this sound.

Someone else brought up an interesting aspect, if the DSP is done in the DAC, it can't be applied to the S/PDIF or USB. For just straight playback, that won't matter since the only thing I will be doing with at least at first is the interpolation filter, which is already included in any external DAC. For long term GEN2 it might be best to have the FPGA DSP based system, then you can do anything you want and it will be useful for all outputs. But that is definitely NOT going to be in GEN1.

I did some more poking around the processor/memory issues, it's a bit more complicated than I thought at first. It looks like the best bet for GEN1 is a 720MHz processor and 256MB RAM. This does not have TDMI interface, it does have an LCD interface. For GEN2 a 1GHz processor and 512MB RAM, this comes with a full blown video controller and built in HDMI and VGA interface. No need for external chips, just hook up connectors. The GEN1 is a much simpler board layout task so I would like to go with it. I COULD do the faster processor from the get-go, put its more work and costs a little more (about $10 more for the board, about $15 more for the processor and $20 more for the memory).

I actually did a full quote on board costs and its actually right around what I thought, the board and assembly for a GEN1 will be $64 for 25, The GEN2 is about $75. So the rest of the cost is the parts which look like around $90 to $100 for a Gen 1. So that hits the $170 for the board. It's $35 for the wifi module which you can add at any time. The place I'm working with does the parts procurement as well, so it's just send files and money and a couple weeks later get a box of fully assembled boards.

The Gen1 board will have no display, so all development has to be over ssh or serial port. I'll probably put a serial port on it so you can have a hardware console during boot.

So it looks like it will have an ethernet jack, 2 USB-A jacks, serial jack, S/PDIF coax, 2 RCA jacks, SD card (probably a micro), power jack, socket for Wifi module. Anything else I need in there?

The big question is, should it have a headphone jack. The easy, inexpensive headphone circuits are not all that great and add more complexity to the board. I know how to make a REALLY good headphone amp, but it will add quite a bit of complexity to the board and some extra cost. So what are your thoughts:
1; no headphone jack
2; simple, cheap, not so great
3; whole hog really good, but complex and pricy.

Also should it have a TOSLINK?

John S.

Hello John,
Once again, I must say a BIG THANK YOU for all of the work you have already contributed! I do not think we would have an issue at all achieving the 25 unit order.

My thoughts for the Headphone jack for GEN1 is "simple, cheap, not so great". We can always change that later with GEN2. If TOSLINK is possible without introducing complexity I say we should include it.

I have started a list of things we will need going forward. Please include your username for anything you want to help or assist with and copy and paste this list in your post (so it continues to grow):
1) Hardware design and implementation - John S.
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustin (Me)
3) Squeezelite Player - Triode
4) Case design - ? (Any designers out there with CAD abilities)
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) Marketing/Name of the new product- This is really for in the future but never to early to start thinking about it
7) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - (Not sure we want to have these items spread all throughout this forum...I think we should have a dedicated site)

Thanks!
Dustin

simbo
2013-01-28, 08:50
1) Hardware design and implementation - John S.
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustin (Me)
3) Squeezelite Player - Triode
4) Case design - ? (Any designers out there with CAD abilities)
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) Marketing/Name of the new product- This is really for in the future but never to early to start thinking about it
7) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - (Not sure we want to have these items spread all throughout this forum...I think we should have a dedicated site)

A couple more to add...
8) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.)
9) Localisation

cparker
2013-01-28, 09:07
7) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - (Not sure we want to have these items spread all throughout this forum...I think we should have a dedicated site)

Thanks!
Dustin

Hi Dustin,

I can help with 7) As a side job alongside plugin development and my full time paid job, I also do ad-hoc web site development (HTML5) based on PHP/mySQL.

Example of a recent bespoke site, fully database driven with full Paypal functionality. (Also at the backend for order fulfilment; there are auto generated shipping emails and shipping documentation etc which reduces admin overhead);
http://www.moonsugar.co.uk

If its of interest drop me a line via PM here or contact me via my website to discuss the intricacies.

Cheers

pssc
2013-01-28, 09:13
If we had reliable usb we could use display link screens at least for some development of graphical based interface. Even if there is no need for a usb DAC straight off.

Phill.

dustinsterk
2013-01-28, 09:49
Hi Dustin,

I can help with 7) As a side job alongside plugin development and my full time paid job, I also do ad-hoc web site development (HTML5) based on PHP/mySQL.

Example of a recent bespoke site, fully database driven with full Paypal functionality. (Also at the backend for order fulfilment; there are auto generated shipping emails and shipping documentation etc which reduces admin overhead);
http://www.moonsugar.co.uk

If its of interest drop me a line via PM here or contact me via my website to discuss the intricacies.

Cheers

That sounds wonderful! PMed.

dustinsterk
2013-01-28, 09:51
A couple more to add...
8) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.)
9) Localisation

Thanks!

1) Hardware design and implementation - JohnSwenson
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustinsterk (Me)
3) Squeezelite Player - Triode
4) Case design - ? (Any designers out there with CAD abilities)
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) Marketing/Name of the new product- (This is really for in the future but never to early to start thinking about it)
7) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - Cparker
8) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.) - ?
9) Localisation - ?

Please continue to add as you see fit.

Thanks!

eLR!C
2013-01-28, 10:17
I can provide help on :
2/ Compiling OS, building automated scripts, etc.
9/ Localisation (French)

I would also add a X/ Testing :)

Some thoughts related to the DAC part : discussing with Triode on the squeezelite thread, I understood that the crystal frequancy of the DAC may make it more or less compatible (from a synchronization perspective) with existing squeezeboxes. That may be something to keep in mind for design.

mherger
2013-01-28, 10:21
> 9) Localisation - ?

How much localization do you expect there to be? Manuals? Web site?

dustinsterk
2013-01-28, 10:23
I can provide help on :
2/ Compiling OS, building automated scripts, etc.
9/ Localisation (French)

I would also add a X/ Testing :)

Some thoughts related to the DAC part : discussing with Triode on the squeezelite thread, I understood that the crystal frequancy of the DAC may make it more or less compatible (from a synchronization perspective) with existing squeezeboxes. That may be something to keep in mind for design.

Thank you!

1) Hardware design and implementation - JohnSwenson
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustinsterk (Me), eLR!C
3) Squeezelite Player - Triode
4) Case design - ? (Any designers out there with CAD abilities)
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) Marketing/Name of the new product- (This is really for in the future but never to early to start thinking about it)
7) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - Cparker
8) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.) - ?
9) Localisation - eLR!C (French)
10) Testing (Hardware, Software, etc) - ?

Please continue to add as you see fit.

dustinsterk
2013-01-28, 10:25
> 9) Localisation - ?

How much localization do you expect there to be? Manuals? Web site?

I would say we are still too early to tell. This could range from manuals/websites to UI on the player itself (for GEN2).

erland
2013-01-28, 10:56
Thank you!

1) Hardware design and implementation - JohnSwenson
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustinsterk (Me), eLR!C
3) Squeezelite Player - Triode
4) Case design - ? (Any designers out there with CAD abilities)
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) Marketing/Name of the new product- (This is really for in the future but never to early to start thinking about it)
7) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - Cparker
8) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.) - ?
9) Localisation - eLR!C (French)
10) Testing (Hardware, Software, etc) - ?

Please continue to add as you see fit.

My suggestion would be to keep the thread focused at point 1-3 and possibly 4 and 5 because those are the only ones needed to start experimenting with GEN1 hardware.
The future after GEN1 is best decided and discussed either in a separate thread or later when GEN1 has been released.

I hate to kill the discussion, I'm just worried that we will make it harder for John and the others to discuss technical details if we start to fill the thread with activities (6-10) which doesn't need to happen in the near future.

If there is a designer reading this thread, I'd really love a nice case designed for it which we could order through http://www.shapeways.com/ or similar sites.

Regarding point 7, I actually think you want to keep it on the forum now in the beginning, mainly because it will make the activities more visible to community members and this will make it easier to reach higher volumes when ready to release GEN2 hardware. The actual files could be hosted somewhere else but keep the discussion and news in the forum to keep the interest in the community.

simbo
2013-01-28, 12:03
> 9) Localisation - ?
How much localization do you expect there to be? Manuals? Web site?


I would say we are still too early to tell. This could range from manuals/websites to UI on the player itself (for GEN2).

I was initially thinking of string translation tables for the UI, but it could cover all those areas and more. Maybe just a form of representation from major regions would be a good start, to ensure the product doesn't become US/UK-centric (as many often do).

TheLastMan
2013-01-28, 12:22
If there is a designer reading this thread, I'd really love a nice case designed for it which we could order through http://www.shapeways.com/ or similar sites.
Prototypes only I presume? Seeing as this will essentially be a "small black box" with no display or control switching then let "form follow function" and keep it simple. No design really necessary. A rectangular metal box to fit round the PCB (which will dictate the size) with a plate at the back for the ports. On/off power switch and light on the front panel would be handy too. Possibly a set of status LEDs rather than the Receivers single light would be good. One to indicate power, one to indicate network (wi-fi or cable) is connected and one to indicate a link to a server.

Personally I like extruded aluminium cases with a nice solid slab of brushed aluminium as a facia either silver or with a black finish to match existing hi-fi equipment.
Something like this? (obviously without volume control)
14355
What do others think?

mherger
2013-01-28, 12:27
I was initially thinking of string translation tables for the UI, but it could cover all those areas and more. Maybe just a form of representation from major regions would be a good start, to ensure the product doesn't become US/UK-centric (as many often do).

Count me in for German anyway (and excuse my adding some Swiss-German touch to it ;-))

Mark Miksis
2013-01-28, 12:34
Hello John,
I have started a list of things we will need going forward. Please include your username for anything you want to help or assist with and copy and paste this list in your post (so it continues to grow):
1) Hardware design and implementation - John S.
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustin (Me)
3) Squeezelite Player - Triode
4) Case design - ? (Any designers out there with CAD abilities)
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) Marketing/Name of the new product- This is really for in the future but never to early to start thinking about it
7) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - (Not sure we want to have these items spread all throughout this forum...I think we should have a dedicated site)

Probably should add controller apps to this list. I presume that the Logitech phone app is at or near its end of life for maintenance. I suppose Pippin and others will continue to support and develop their products as long as there is a revenue stream, but it appears that SqueezeCommander, as an example, is no longer maintained. It would be nice to have an open-source multi-platform app as part of this project.

erland
2013-01-28, 12:54
Prototypes only I presume? Seeing as this will essentially be a "small black box" with no display or control switching then let "form follow function" and keep it simple. No design really necessary. A rectangular metal box to fit round the PCB (which will dictate the size) with a plate at the back for the ports. On/off power switch and light on the front panel would be handy too. Possibly a set of status LEDs rather than the Receivers single light would be good. One to indicate power, one to indicate network (wi-fi or cable) is connected and one to indicate a link to a server.

The fact that it doesn't have a display doesn't mean that I don't want people to see it, I want show what people in the Squeezebox community has accomplished and then it needs to look nice. Maybe not important for GEN1 but definitely for GEN2.

Maybe a transparent box so we can see the board, something similar to this Raspberry Pi case:
http://www.adafruit.com/blog/2012/05/29/raspberry-pi-case-preview/
(In this case I want the circuit board personally signed by John since I will be able to view the signature through the transparent case)
:-)

As an alternative, I guess I could always build one myself with lego:
http://www.thedailybrick.co.uk/lego-sets/custom/lego-custom-raspberry-pi-case.html

dustinsterk
2013-01-28, 13:08
The fact that it doesn't have a display doesn't mean that I don't want people to see it, I want show what people in the Squeezebox community has accomplished and then it needs to look nice. Maybe not important for GEN1 but definitely for GEN2.

Maybe a transparent box so we can see the board, something similar to this Raspberry Pi case:
http://www.adafruit.com/blog/2012/05/29/raspberry-pi-case-preview/
(In this case I want the circuit board personally signed by John since I will be able to view the signature through the transparent case)
:-)

As an alternative, I guess I could always build one myself with lego:
http://www.thedailybrick.co.uk/lego-sets/custom/lego-custom-raspberry-pi-case.html

Haha...I second this. Maybe not GEN1, but eventually I want a pretty case for it.

didjean
2013-01-28, 13:30
I hate to kill the discussion, I'm just worried that we will make it harder for John and the others to discuss technical details if we start to fill the thread with activities (6-10) which doesn't need to happen in the near future.

Totally agree with this. First things first!
My centre of expertise is between 6-10. I would be more than happy to help as soon as you really need me :-)

dustinsterk
2013-01-28, 14:01
Totally agree with this. First things first!
My centre of expertise is between 6-10. I would be more than happy to help as soon as you really need me :-)

This is fine, lets just focus on 1-5 for now to keep it relevant.....6-10 can come at a later date when it is needed:

GEN1:
1) Hardware design and implementation - JohnSwenson
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustinsterk (Me), eLR!C
3) Squeezelite Player - Triode
4) Case design - ? (Any designers out there with CAD abilities)
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)

GEN2:
6) Marketing/Name of the new product- (This is really for in the future but never to early to start thinking about it)
7) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - Cparker
8) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.) - ?
9) Localisation - eLR!C (French), mherger (German)
10) Testing (Hardware, Software, etc) - ?

chill
2013-01-28, 14:03
Maybe a transparent box so we can see the board, something similar to this Raspberry Pi case:
http://www.adafruit.com/blog/2012/05/29/raspberry-pi-case-preview/
(In this case I want the circuit board personally signed by John since I will be able to view the signature through the transparent case)
:-)

I have one of these for my Raspberry Pi, and I think such a case would be a good option for our player. Once the design's done it's dirt cheap to make for someone with the right tool, and it's beautifully simple to assemble, with no screws or fixings, just some clever sprung lugs built into the design. I'd favour the transparent one myself, but you can start with any colour of perspex that you like. I think a shiny black one would look good too.

Triode
2013-01-28, 14:07
This is fine, lets just focus on 1-5 for now to keep it relevant.....6-10 can come at a later date when it is needed:

GEN1:
1) Hardware design and implementation - JohnSwenson
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustinsterk (Me), eLR!C
3) Squeezelite Player - Triode
4) Case design - ? (Any designers out there with CAD abilities)
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)

GEN2:
6) Marketing/Name of the new product- (This is really for in the future but never to early to start thinking about it)
7) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - Cparker
8) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.) - ?
9) Localisation - eLR!C (French), mherger (German)
10) Testing (Hardware, Software, etc) - ?

For Gen 1: I think we should add wiki/manual writing to explain to users how to use it. I think this should be one or more people who don't do the development as I often find that what's obvious to me is not obvious to others.

bluegaspode
2013-01-28, 14:15
Maybe a transparent box so we can see the board, something similar to this Raspberry Pi case:
http://www.adafruit.com/blog/2012/05/29/raspberry-pi-case-preview/
(In this case I want the circuit board personally signed by John since I will be able to view the signature through the transparent case)
:-)

Like transparent :)
But you need some additional LEDs on the board then ...

8x8 anyone: http://www.adafruit.com/products/1051 ??

norman12
2013-01-28, 14:20
I don't post much, but I often pop in - this thread has to be the most interesting for some time.

I'm happy to help with case design if needed.
I've a fair amount of engineering experience along with 3D CAD.

norm.

P Nelson
2013-01-28, 14:45
For Gen 1: I think we should add wiki/manual writing to explain to users how to use it. I think this should be one or more people who don't do the development as I often find that what's obvious to me is not obvious to others.

That second point of obvious to one person is NOT so obvious for antoher is very true! Especially if you want a music enthusiast that is not a computer expert use GEN1 or GEN2. Sometimes on these forums I don't understand the instructions that are listed. Especially when they are in the Linux environment, which I have little knowledge.

JohnSwenson
2013-01-28, 14:48
Hello John,
Once again, I must say a BIG THANK YOU for all of the work you have already contributed! I do not think we would have an issue at all achieving the 25 unit order.

My thoughts for the Headphone jack for GEN1 is "simple, cheap, not so great". We can always change that later with GEN2. If TOSLINK is possible without introducing complexity I say we should include it.

I have started a list of things we will need going forward. Please include your username for anything you want to help or assist with and copy and paste this list in your post (so it continues to grow):
1) Hardware design and implementation - John S.
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustin (Me)
3) Squeezelite Player - Triode
4) Case design - ? (Any designers out there with CAD abilities)
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) Marketing/Name of the new product- This is really for in the future but never to early to start thinking about it
7) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - (Not sure we want to have these items spread all throughout this forum...I think we should have a dedicated site)

Thanks!
Dustin

One thing to add is the internal web server and configuration pages. Since this is not having a display it needs an internal web server for configuration issues. We need the web server it self, UI pages the users see, and what happens when the user modifies something on the page.

John S.

JohnSwenson
2013-01-28, 14:59
Just read through the usb section of the data sheet again - it doesn't seem to be the same as EHCI, but lets hope it works... EHCI keeps a schedule of the next several frames worth of transactions in a shared memory block and doesn't require interrupts per packet/frame - it looks like this does.. [In contrast the AM37x technical reference manual includes all the details of EHCI and register maps I would expect - there's definitely a difference between it and the AM335x from the data sheet.]

Lets keep our fingers crossed! Could you test full speed and high speed devices. There is no mention of split transactions in the datasheet, so I wonder how TT works - perhaps if we only have support for native full speed or native high speed this does not matter.

How about the AM3874? This is what I was planning on using For Gen2 since it has all the display stuff builtin. According to the technical manual the USB system DOES have a hardware scheduler, checking the details you can turn off packet interrupts if using DMA so it looks like this might be better.

If this looks like a better USB architecture to use, I could go with this processor for Gen1 and leave off all the display stuff, just do a quick and dirty Gen1 implementation. If the USB implementations are significantly different enough that there are questions about it's usefullness then it is probably better to use the same processor for both Gen1 and Gen2. The problem is that I think it's going to take an 8 layer board to do the AM3874, that will add a little more cost to the board -- I just checked it's only $6 more per board to go with 8 layer. OK I think I just convinced myself to go with the AM3874 for both Gen1 and Gen2.

I'll still check and see if the BeagleBone works with the UAC1, UAC2 etc. If it does that probably means that the AM3874 will probably also work. Unfortunately I have not found out what USB module it uses. I guess I will have to download the linux SDK and find out!

John S.

epoch1970
2013-01-28, 15:00
I can serve as a backup frenchman for localization.
Some time ago I was supposed to be able to write technical documentation.
I suspect I'll have some free time in spring/summer…

simbo
2013-01-28, 15:09
My suggestion would be to keep the thread focused at point 1-3 and possibly 4 and 5 because those are the only ones needed to start experimenting with GEN1 hardware.
The future after GEN1 is best decided and discussed either in a separate thread or later when GEN1 has been released.

Although I agree 1-5 are the most critical, they're not necessarily prerequisites to the later areas. I think we need to structure the discussions into the various "streams"... Is there a way we could manage this, either through this forum or another?

I would personally like to see a whole forum devoted to this, categorised by the streams being discussed. Perhaps your Google Discussions board could do this? I'm not sure of the functionality available there.

One thing's for sure, this thread is going to become unmanageable soon!

JohnSwenson
2013-01-28, 15:10
I do think we need a name for the project, so I can quick calling it "the box" or "that thing". In my own mind I have started calling it "OSB": Open Squeeze Box. That's the best I can come up for now.

John S.

dustinsterk
2013-01-28, 15:16
One thing to add is the internal web server and configuration pages. Since this is not having a display it needs an internal web server for configuration issues. We need the web server it self, UI pages the users see, and what happens when the user modifies something on the page.

John S.

Agreed and added.

GEN1:
1) Hardware design and implementation - JohnSwenson
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustinsterk (Me), eLR!C
3) Squeezelite Player - Triode
4) Case design - norman12
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) WIKI setup and updating for instuctional use of new device (from NON tech person(s)) - ?
7) Creation and setup of internal webserver configuration page hosted on OS of the device. - ?

GEN2:
8) Marketing/Name of the new product- (This is really for in the future but never to early to start thinking about it)
9) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - Cparker
10) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.) - ?
11) Localisation - eLR!C (French), mherger (German), epoch1970 (French)
12) Testing (Hardware, Software, etc) - ?

dustinsterk
2013-01-28, 15:17
I don't post much, but I often pop in - this thread has to be the most interesting for some time.

I'm happy to help with case design if needed.
I've a fair amount of engineering experience along with 3D CAD.

norm.

Norm,
That is great....with John's design work I am sure we can get you a version/schematic for a case mockup.

Thanks!

Triode
2013-01-28, 15:23
How about the AM3874? This is what I was planning on using For Gen2 since it has all the display stuff builtin. According to the technical manual the USB system DOES have a hardware scheduler, checking the details you can turn off packet interrupts if using DMA so it looks like this might be better.


This still looks like the more limited hardware:

"An interrupt is generated whenever a packet is received from the host and the software may use this
interrupt to unload the packet from the FIFO and clear the RXPKTRDY bit in the PERI_RXCSR
register (bit 0) in the same way as for a Bulk Rx endpoint. As the interrupt could occur almost any time
within a frame(/microframe), depending on when the host has scheduled the transaction, the timing of
FIFO unload requests will probably be irregular. If the data sink for the endpoint is going to some
external hardware, it may be better to minimize the requirement for additional buffering by waiting until
the end of each frame(/microframe) before unloading the FIFO."

It may work fine - all I'm saying is that its not EHCI which I suspect needs more gates to implement as there's no need for an interrupt per packet. If you compare the usb section with the usb host port section in the AM3715 reference manual you will see the difference. This looks to have separate host and otg hardware - the host port is ehci/ohci, whereas the otg is the mentor block.

Lets see what your Beagle Bone does when you get it and then review.

epoch1970
2013-01-28, 15:44
I do think we need a name for the project, so I can quick calling it "the box" or "that thing". In my own mind I have started calling it "OSB": Open Squeeze Box.
Is using the word(s) Squeeze Box really advisable ?
I name my players with places where I remember hearing good music, or generally having a good time…

P Nelson
2013-01-28, 19:48
Is using the word(s) Squeeze Box really advisable ?
I name my players with places where I remember hearing good music, or generally having a good time…

I agree.

Does anyone remember the old wind up music boxes? For the development why not call is OS music box. Where OS stands for open source.

I cannot help with the technical, but I will give some names some more thinking.

Paul

JJZolx
2013-01-28, 19:49
Squeezebox, not Squeeze Box.

dustinsterk
2013-01-28, 20:20
I do think we need a name for the project, so I can quick calling it "the box" or "that thing". In my own mind I have started calling it "OSB": Open Squeeze Box. That's the best I can come up for now.

John S.

Whenever I hear the name Squeezebox it has always reminded me of the child drink boxes. Any opinions on any of the following names.... Thinking out loud:

Juice Box
Fresh squeeze (like the orange juice)
Juicey Juice (although this is a brand name)
O. J. (like orange juice but an acronym for 'Open Juice')


You can be honest if you hate them all. I am just rambling.

JJZolx
2013-01-28, 20:42
Personally I like extruded aluminium cases with

I do too, but that would dictate using an external antenna, would it not?

erland
2013-01-28, 20:46
Although I agree 1-5 are the most critical, they're not necessarily prerequisites to the later areas. I think we need to structure the discussions into the various "streams"... Is there a way we could manage this, either through this forum or another?

I would personally like to see a whole forum devoted to this, categorised by the streams being discussed. Perhaps your Google Discussions board could do this? I'm not sure of the functionality available there.

One thing's for sure, this thread is going to become unmanageable soon!

Just start a few separate threads and you will get the structure you want. Moving all discussion away from this forum is just going to be bad for it because it means that you will loose a lot of potential people who happened to do other things during the last week when this thread started to become active.

pippin
2013-01-28, 20:58
My 2cts for a name:

DFCOJ
Developers from the Forum Create an Open Jukebox
:)

erland
2013-01-28, 21:12
I do think we need a name for the project, so I can quick calling it "the box" or "that thing". In my own mind I have started calling it "OSB": Open Squeeze Box. That's the best I can come up for now.

I would avoid the word Squeeze for a number of reasons:
- "Squeezebox" is a registered trademark and can't be used, putting a space in-between "Squeeze" and "Box" is still pretty close to the registered trademark.
- "Squeeze" indicates to me that it's always going to be use together with LMS and mysqueezebox.com and as I tried to indicate earlier in the thread that might not necessarily be the case on longer terms if this becomes something bigger than a geek project. Eventually, we need to at least break loose from mysqueezebox.com if we want it to be something else than a temporary solution.

I'm really bad at naming, but I would prefer "Open Music Box" (OMB) or "Open Stream Box" (OSB) before "Open Squeeze Box".
Another boring alternative would be TMB (The Music Box or The Magic Box).

(John, I sent you a PM yesterday which is somewhat related to this thread)

P Nelson
2013-01-28, 22:01
Rising up out of the ashes of logitech: Phoenix.

Mnyb
2013-01-28, 23:04
I tend to agre with Erland here , who knows if slim proto ( or what's it's called ) is the only thing it it will understand .

Why not JS1 but in reality it might be JS347 :P (if DAC design is one of his hobbies ).

chill
2013-01-29, 02:00
How about a name that's related to Squeezebox, without running into trademark problems. How about 'Accordion'?

lrossouw
2013-01-29, 02:24
I love thinking of names. Some ideas:
Harmonica
MusicBox
TheDAC
MusicPipe
On Tap Music
Music on Tap
Music on Call
Touch
MusicPi <- if based on R Pi
Blender <- instead of squeeze
MusicBits
BeatBit

It's going to be open right?
OpenBox
OpenTunes
OpenHiFi
OpenTransport <- like this one
OpenMusicBox
OpenPlayer

simbo
2013-01-29, 02:57
Could we get a "Slim" in there? In homage to the original creators? :-)

CharlieG
2013-01-29, 03:42
Rising up out of the ashes of logitech: Phoenix.

I liked Phoenix Music Streamer...until I realized the acronym would be PMS :)
Having “Music Streamer” in the name might help with marketing in the long term tho.

simbo
2013-01-29, 04:11
I've created a separate thread for a discussion on the naming, to ease up this thread for more primary discussions...

http://forums.slimdevices.com/showthread.php?97975

castalla
2013-01-29, 04:17
I liked Phoenix Music Streamer...until I realized the acronym would be PMS :)
Having “Music Streamer” in the name might help with marketing in the long term tho.

How about something snappy ...

eXprimo

(Spanish for 'I squeeze'!)

... notice the capitalised 'x' !

TheLastMan
2013-01-29, 04:37
I liked Phoenix Music Streamer...until I realized the acronym would be PMS :)
Having “Music Streamer” in the name might help with marketing in the long term tho.
The last few posts remind me of a Douglas Adams's Hitch Hiker story that humans are the descendants of exiled Golgafrinchan management consultants, hair dressers, telephone sanitizers and marketing executives.

The Golgafrinchan race thought they would be so much better off without all the useless service sector workers and middle management. So they stuck them on a space ship and shot them across the galaxy. They eventually landed on the Earth where they set about trying to establish civilization.

There was a marketing executive character who was working on developing the wheel but she was struggling to get started because she couldn't decide what colour it should be.

I think Mr Adams may have been on to something...

I think Simbo is trying the same trick as the Golgafrinchans ;)

simbo
2013-01-29, 04:40
I think Simbo is trying the same trick as the Golgafrinchans
:-) The way I look at it, these kind of "what shall we call it?" discussions are inevitable, and as long as they don't detract from the more pressing discussions over architecture and design (which is why I wanted to separate them out) then I see no harm... I think they're actually a good thing as they give contributors a sense of ownership and community.

EDIT: Oh, and I've always seen myself as an "A-Ark" kind of person... but sometimes at work I have to wonder ;-)

dustinsterk
2013-01-29, 10:11
:-) The way I look at it, these kind of "what shall we call it?" discussions are inevitable, and as long as they don't detract from the more pressing discussions over architecture and design (which is why I wanted to separate them out) then I see no harm... I think they're actually a good thing as they give contributors a sense of ownership and community.

EDIT: Oh, and I've always seen myself as an "A-Ark" kind of person... but sometimes at work I have to wonder ;-)

Simbo,
Thanks for separating that out in a new thread. Back to the technical discussions....

Question for John.....when it comes to distribution, once the order is placed will the product need to ship to just one location and distribute to end buyers from there? I am located in the USA in the state or Delaware/Pennsylvania (right on the border). It seems the majority of this community is in the EU or UK. John, where are you located? Will you need assistance with this process? You are already doing a lot so I want to assist in any way possible.

Thanks!
Dustin

maggior
2013-01-29, 13:01
The last few posts remind me of a Douglas Adams's Hitch Hiker story that humans are the descendants of exiled Golgafrinchan management consultants, hair dressers, telephone sanitizers and marketing executives.

The Golgafrinchan race thought they would be so much better off without all the useless service sector workers and middle management. So they stuck them on a space ship and shot them across the galaxy. They eventually landed on the Earth where they set about trying to establish civilization.

There was a marketing executive character who was working on developing the wheel but she was struggling to get started because she couldn't decide what colour it should be.

I think Mr Adams may have been on to something...

I think Simbo is trying the same trick as the Golgafrinchans ;)

That part of the book was brilliant and was greatly realized in the TV series. My favorite was fire. Ford Prefect (if not him than it was Arthur Dent) suggested he put something up his nose, to which the marketing person responded "yes, that's right...would people want to have fire fitted nasally?". All of this going one while the captain of the ship sits in the bath.

Genius!

Rosewind
2013-01-29, 13:04
Interesting thread.

SlimBox?

Best wishes,
Peter

JohnSwenson
2013-01-29, 13:24
Simbo,
Thanks for separating that out in a new thread. Back to the technical discussions....

Question for John.....when it comes to distribution, once the order is placed will the product need to ship to just one location and distribute to end buyers from there? I am located in the USA in the state or Delaware/Pennsylvania (right on the border). It seems the majority of this community is in the EU or UK. John, where are you located? Will you need assistance with this process? You are already doing a lot so I want to assist in any way possible.

Thanks!
Dustin

I'm in California, San Francisco Bay area in specific, the place I'm having do the boards is in Canada, somewhere in Ontario. I would GREATLY appreciate someone else taking charge of distribution of boards.

The other issue is money. Kickstarter might be a nice way to do this, since they take care of everything. For the first phase it doesn't even have to be a fancy video etc, at this point we are not looking to have large numbers of "the public" in on the development board. Or maybe that is TOO public for the devdelopment phase.

John S.

dustinsterk
2013-01-29, 13:32
I'm in California, San Francisco Bay area in specific, the place I'm having do the boards is in Canada, somewhere in Ontario. I would GREATLY appreciate someone else taking charge of distribution of boards.

The other issue is money. Kickstarter might be a nice way to do this, since they take care of everything. For the first phase it doesn't even have to be a fancy video etc, at this point we are not looking to have large numbers of "the public" in on the development board. Or maybe that is TOO public for the devdelopment phase.

John S.

I would be happy to start a Kickstarter Project site. It will take some time to get setup with amazon payments, etc. Is our goal 25 boards @ $150 a board for all of the goodies?

JohnSwenson
2013-01-29, 13:44
I have been looking into what processor to use, IF the BeagleBone tests go well I would like to keep it with the TI processor line I have been looking at, they have really good support systems behind it, much better than many of the other manufacturers, which will make getting a board out much quicker. In particular they have spent a lot of effort optimizing their ball layout to make it easier to layout these large BGAs, which makes my task much easier to do than if we used another company's competing products.

If things turn out I have a dilema, which processor to use, the AM3358 or the AM3874. The AM3358 is $20 cheaper, has a much smaller package which is easier to route. Mostly because it does not have a display subsystem so there are much fewer pins. It also hassome limitations on what memory chips it can take. The max speed is 720MHz.

The AM3874 has a max speed of 1GHz, has a full blown display subsystem with HDMI, VGA, component video etc all built in to the chip. It's memory interface is more flexible so it can support the larger single chip memories. This is the chip I was thinking of using for Gen2.

So what do we use for Gen1? The max memory in one chip you can use for the 3358 is 256MB, but you can get up to 512GB with the 3874 but it costs $20 more to do that.

I looked carefully at the 3874 pinout and found that TI has done a really good job making it easy to route, so that part is not as bad as I thought originaly.

I'm leaning on just going with the 3874 for Gen1 so it is the same as Gen2, just not the display subsystem etc. Just doing that increases the cost by about $35, so we are now up to $205, if we go with the 512MB that adds another $25 or so, so we are now up to $230, $60 more than I originally predicted.

What do you all think?

John S.

tcutting
2013-01-29, 13:53
I like the idea of Gen1 and Gen2 having same processor. It seems to make sense to figure things out the first time around and not get surprised by something subtly different on Gen2.

Sent from my DROID RAZR using Tapatalk 2

dustinsterk
2013-01-29, 14:30
I have been looking into what processor to use, IF the BeagleBone tests go well I would like to keep it with the TI processor line I have been looking at, they have really good support systems behind it, much better than many of the other manufacturers, which will make getting a board out much quicker. In particular they have spent a lot of effort optimizing their ball layout to make it easier to layout these large BGAs, which makes my task much easier to do than if we used another company's competing products.

If things turn out I have a dilema, which processor to use, the AM3358 or the AM3874. The AM3358 is $20 cheaper, has a much smaller package which is easier to route. Mostly because it does not have a display subsystem so there are much fewer pins. It also hassome limitations on what memory chips it can take. The max speed is 720MHz.

The AM3874 has a max speed of 1GHz, has a full blown display subsystem with HDMI, VGA, component video etc all built in to the chip. It's memory interface is more flexible so it can support the larger single chip memories. This is the chip I was thinking of using for Gen2.

So what do we use for Gen1? The max memory in one chip you can use for the 3358 is 256MB, but you can get up to 512GB with the 3874 but it costs $20 more to do that.

I looked carefully at the 3874 pinout and found that TI has done a really good job making it easy to route, so that part is not as bad as I thought originaly.

I'm leaning on just going with the 3874 for Gen1 so it is the same as Gen2, just not the display subsystem etc. Just doing that increases the cost by about $35, so we are now up to $205, if we go with the 512MB that adds another $25 or so, so we are now up to $230, $60 more than I originally predicted.

What do you all think?

John S.

I also agree that it makes sense to stick with the same processor. Since this is GEN1, I think we should go for less RAM at the decreased expense as we have to also add the costs for the wireless module. This would bring the grand total to $235 for a unit all in (no case included). Please correct me if I am wrong.

Triode
2013-01-29, 14:35
I have been looking into what processor to use, IF the BeagleBone tests go well I would like to keep it with the TI processor line I have been looking at, they have really good support systems behind it, much better than many of the other manufacturers, which will make getting a board out much quicker. In particular they have spent a lot of effort optimizing their ball layout to make it easier to layout these large BGAs, which makes my task much easier to do than if we used another company's competing products.

If things turn out I have a dilema, which processor to use, the AM3358 or the AM3874. The AM3358 is $20 cheaper, has a much smaller package which is easier to route. Mostly because it does not have a display subsystem so there are much fewer pins. It also hassome limitations on what memory chips it can take. The max speed is 720MHz.

The AM3874 has a max speed of 1GHz, has a full blown display subsystem with HDMI, VGA, component video etc all built in to the chip. It's memory interface is more flexible so it can support the larger single chip memories. This is the chip I was thinking of using for Gen2.

So what do we use for Gen1? The max memory in one chip you can use for the 3358 is 256MB, but you can get up to 512GB with the 3874 but it costs $20 more to do that.

I looked carefully at the 3874 pinout and found that TI has done a really good job making it easy to route, so that part is not as bad as I thought originaly.

I'm leaning on just going with the 3874 for Gen1 so it is the same as Gen2, just not the display subsystem etc. Just doing that increases the cost by about $35, so we are now up to $205, if we go with the 512MB that adds another $25 or so, so we are now up to $230, $60 more than I originally predicted.

What do you all think?

John S.

Lets see how the async usb tests go - if the otg port works then the 3358 seems resonable for the first gen. Means there's less code to write too :)

dustinsterk
2013-01-29, 14:35
John,
As a side note for the kickstarter site. I cannot create anything until the following has been completed. So we maybe a little early for it just yet. I may need to have a more formal discussion with you once this is a little further along:


A functional prototype. Projects in the back-of-a-napkin or 3D-rendering phase are too early to raise funds on Kickstarter. Projects must have at least a functional prototype before launching on Kickstarter.

A production plan. How and where will you be making your project? Share the details on how you will complete it. This must be established prior to launch.


--Dustin

erland
2013-01-29, 15:49
I'm leaning on just going with the 3874 for Gen1 so it is the same as Gen2, just not the display subsystem etc. Just doing that increases the cost by about $35, so we are now up to $205, if we go with the 512MB that adds another $25 or so, so we are now up to $230, $60 more than I originally predicted.

What do you all think?

The price isn't important in GEN1, but don't add stuff in GEN1 unless it will make yours or the software developers work with GEN1 simpler.
So:
- if you think it will decrease the work for you if you go with 3874 in both GEN1 and GEN2, let's do that.
- if you think it will decrease the work for you to go with 3358 in GEN1 and upgrade to 3874 in GEN2, let's do that.

Don't add more memory than absolutely needed in GEN1, 256MB is fine, 128MB is also fine if we can spare some money or work by selecting it. Nobody is going to do anything with GEN1 that requires more than 128MB, probably even 64MB (as Squeezebox Radio) is ok for GEN1.

erland
2013-01-29, 15:51
Lets see how the async usb tests go - if the otg port works then the 3358 seems resonable for the first gen. Means there's less code to write too :)

One thing I still don't completely understand is how important the USB really is if we:
1. Have a DAC that generally produce a better analogue out than everything else than high-end external DAC's
2. Have a S/PDIF that's significantly better than the Squeezebox Touch

Are all new external high-end DAC's USB only (without support for S/PDIF) or why is USB that important if we have an excellent S/PDIF and an excellent analogue out ?

Triode
2013-01-29, 15:59
One thing I still don't completely understand is how important the USB really is if we:
1. Have a DAC that generally produce a better analogue out than everything else than high-end external DAC's
2. Have a S/PDIF that's significantly better than the Squeezebox Touch

Are all new external high-end DAC's USB only (without support for S/PDIF) or why is USB that important if we have an excellent S/PDIF and an excellent analogue out ?

It will be for the audiophile community which wants to use usb (several people using touch for this for example). Some dacs work best with usb others best with spdif. John can comment in more detail than me, but I think we need to make sure both work. Otherwise there will be a parallel development of people wanting usb dacs and looking at other hardware which will fragment the effort....

erland
2013-01-29, 16:05
I would be happy to start a Kickstarter Project site. It will take some time to get setup with amazon payments, etc. Is our goal 25 boards @ $150 a board for all of the goodies?

Just some thoughts regarding this.

Do you really need/want a kickstarter project for GEN1 ?

My feeling is that GEN1 might be easier to handle just through PayPal or similar, I suspect you won't have any problem what so ever to find 25 people interested, what will be harder is to select which 25 to give the opportunity to buy GEN1 to ensure that you get as much useful feedback as possible during GEN1 testing phase to make it possible to prepare for GEN2 as much as possible. You don't want to end up in a scenario where the people with the best experience for the testing phase doesn't get a GEN1 board just because there are more than 25 non technical donators volunteering to get GEN1 first. The only reason I can see to go with kickstarter for GEN1, is if you like to check the possibility to order a batch of 50 or 100 circuit boards instead of just ordering a batch of 25.

For GEN2, a kickstarter project could make sense, but my guess is that you in this case probably want to decide on the company related stuff before setting up the kickstarter project, because you probably want the kickstarter funds to be payed to the company and not to an individual.

Still, having said all this, it probably makes sense to investigate the terms for setting up a kickstarter project and look around if there are any recommendations what to think about when using kickstarter for a project like this.

JohnSwenson
2013-01-29, 16:25
Just some thoughts regarding this.

Do you really need/want a kickstarter project for GEN1 ?

My feeling is that GEN1 might be easier to handle just through PayPal or similar, I suspect you won't have any problem what so ever to find 25 people interested, what will be harder is to select which 25 to give the opportunity to buy GEN1 to ensure that you get as much useful feedback as possible during GEN1 testing phase to make it possible to prepare for GEN2 as much as possible. You don't want to end up in a scenario where the people with the best experience for the testing phase doesn't get a GEN1 board just because there are more than 25 non technical donators volunteering to get GEN1 first. The only reason I can see to go with kickstarter for GEN1, is if you like to check the possibility to order a batch of 50 or 100 circuit boards instead of just ordering a batch of 25.

For GEN2, a kickstarter project could make sense, but my guess is that you in this case probably want to decide on the company related stuff before setting up the kickstarter project, because you probably want the kickstarter funds to be payed to the company and not to an individual.

Still, having said all this, it probably makes sense to investigate the terms for setting up a kickstarter project and look around if there are any recommendations what to think about when using kickstarter for a project like this.

Yep,
it looks like kickstarter will be much better for GEN2.

My own personal feeling is that we want to keep GEN1 to 25 at least for a while. During the phase where linux distributions are being developed etc it's going to be a VERY geeky thing, I don't want too many non-technical developers involved at that point, it could get a bad reputation. Once a good distribution gets developed so it can be booted up and running Squeezelite without intervention then it's possible to get a wider distribution. At that point we want people to try lots of diffeent DACs etc, make sure things work, and also this is the time where we can look into finding out things like thread priorities, buffer sizes etc. That can do well with interested non-technical people. If the group wants more than 25 GEN1 boards we can always make more (2nd and up batches cost less, a lot of the setup costs have already been paid for).

John S.

epoch1970
2013-01-29, 16:28
Do you really need/want a kickstarter project for GEN1 ?
I tend to agree w/ Erland (his 2 previous posts.)
The way I see it, the honor system + paypal would do fine initially.
I hope there are 25 devs on board ;) and that they'll all have the latitude to spend the money necessary to acquire one GEN1 platform.

However the thread is aptly named "Community Funded Squeezebox Replacement". How about someone (John S. ?) pooling donations from the community at large, to help financing the 1st batch of development machines ?

JohnSwenson
2013-01-29, 16:46
It will be for the audiophile community which wants to use usb (several people using touch for this for example). Some dacs work best with usb others best with spdif. John can comment in more detail than me, but I think we need to make sure both work. Otherwise there will be a parallel development of people wanting usb dacs and looking at other hardware which will fragment the effort....

I think we want to do both USB and S/PDIF. A good impelemetation of async USB is very different than a good implementation of S/PDIF, the result is that most DACs are better at one or the other, even if they contain both inputs.

Theoretically a REALLY well done USB should be better than a REALLY good S/PDIF, but there are so many variables in implementation that making generalizations about existing products is next to impossible.

John S.

dasmueller
2013-01-29, 18:24
Have been following this thread for days. I wish you the best in developing a unit you and others are happy with. While I might be interested in participating, I also understand Erland's discussion of being wary of who is involved. I certainly am no software/computer whizz so would probably not be of any real help. Still, I wish you the best ! I will continue to follow this topic to see how it progresses along it's exciting path.

dustinsterk
2013-01-29, 19:26
Yep,
it looks like kickstarter will be much better for GEN2.

My own personal feeling is that we want to keep GEN1 to 25 at least for a while. During the phase where linux distributions are being developed etc it's going to be a VERY geeky thing, I don't want too many non-technical developers involved at that point, it could get a bad reputation. Once a good distribution gets developed so it can be booted up and running Squeezelite without intervention then it's possible to get a wider distribution. At that point we want people to try lots of diffeent DACs etc, make sure things work, and also this is the time where we can look into finding out things like thread priorities, buffer sizes etc. That can do well with interested non-technical people. If the group wants more than 25 GEN1 boards we can always make more (2nd and up batches cost less, a lot of the setup costs have already been paid for).

John S.


While looking more into the Kickstarter requirements the GEN1 prototype does need to exist first before we could qualify to create a project. Keeping it to a small number of units I think will be very beneficial as it will be very technical at first.

John if things go well with the testing of the 3358, do you have any time estimates on the first order being placed? Are we looking at weeks or months?

dustinsterk
2013-01-29, 19:29
However the thread is aptly named "Community Funded Squeezebox Replacement". How about someone (John S. ?) pooling donations from the community at large, to help financing the 1st batch of development machines ?

Not a bad idea.....but the question remains would the community be willing to donate for the first round? Even at $10.00 a donation we would need over 500 users to reach a goal of 25 units @ $200 a board.

erland
2013-01-29, 22:16
Not a bad idea.....but the question remains would the community be willing to donate for the first round? Even at $10.00 a donation we would need over 500 users to reach a goal of 25 units @ $200 a board.

As someone who have tried donations previously in this community, it would surprise me if it comes anywhere near this amount. When I offered users to voluntarily donate money for my plugins a few years back, I don't think I ever got more than totally $100 during a single month. This project is probably a bit more interesting than my plugins was, so reaching a few hundred dollars might not be unrealistic, but I'm still fairly sure you wouldn't get anywhere near the amounts needed to cover the complete costs pf 25 boards.

The only scenario where donations makes sense is if John would like some compensation for the time and effort he spends on designing the GEN1 boards, but if he wants compensation for this, it's really his choice to either setup a PayPal account for donations or increase the price of the GEN1 boards a bit to cover his efforts.

GEN2 is a different scenario because then we are talking about something that could become a product which people can buy and use themselves, but then it's probably better to handle it through kickstarter or similar site than PayPal donations.

guidof
2013-01-30, 08:54
Not a bad idea.....but the question remains would the community be willing to donate for the first round? Even at $10.00 a donation we would need over 500 users to reach a goal of 25 units @ $200 a board.

We probably won't know the answer to this until we try. Or at least set up a list of pledgers.

For Gen1, it seems like a good idea to limit the number to 25.

For Gen2, I'd be interested in participating if you need any totally non technical folks.

I wish to provide as much encouragement as possible for this worthy initiative!

Regards,

Guido F.

Mnyb
2013-01-30, 09:50
Is hdmi in or out of the picture ?

Not for streaming movies but for multichannel audio , this would also demand some small changes in the server to make it accept 5.1 and 7.1 FLAC and WAV (I mean 24bit lpcm over hdmi )

In many cases with a home cinema hdmi is all you need .

Maybe not for the audiophile as some hdmi implementations are horrific (not all ) , but I have no shortage of inputs so I use will use both :) (coax for stereo sound ) and I have the Meridian HD621 that copes with hdmi jitter problems (so they say ) .

dustinsterk
2013-01-30, 09:53
Is hdmi in or out of the picture ?

Not for streaming movies but for multichannel audio , this would also demand some small changes in the server to make it accept 5.1 and 7.1 FLAC and WAV (I mean 24bit lpcm over hdmi )

In many cases with a home cinema hdmi is all you need .

Maybe not for the audiophile as some hdmi implementations are horrific (not all ) , but I have no shortage of inputs so I use will use both :) (coax for stereo sound ) and I have the Meridian HD621 that copes with hdmi jitter problems (so they say ) .

It seems that for GEN1 it is out ("just not the display subsystem etc" as John stated). It is planned for GEN2 as others want the display aspect.

Mnyb
2013-01-30, 13:03
It seems that for GEN1 it is out ("just not the display subsystem etc" as John stated). It is planned for GEN2 as others want the display aspect.

Yeah ,just an idea there is no discrete multichannel streamer that I know about ? That would be an unique feature .
Possible some oppo blue ray with dlna or some such :/ just basic directory browsing after iso's ? Or files .

JohnSwenson
2013-01-30, 14:37
Yeah ,just an idea there is no discrete multichannel streamer that I know about ? That would be an unique feature .
Possible some oppo blue ray with dlna or some such :/ just basic directory browsing after iso's ? Or files .

Hmmm, I haven't thought too much about multi-channel. The HDMI subsystem takes up to 8 uncompressed channels, purely controlled by software, so nothing is needed at the hardware level to support this. I'll let the software types figure that one out!

As far as other outputs go, the chip has 36 audio output pins, each of which can be either an I2S or S/PDIF, thus up to 72 channels!!! They can be input or output, but cannot be completly independant. Each pin can have different data, but the timing and clocks come in groups. There are 6 groups, 4 of which can handle up to 8 channels per group and 2 groups that can handle up to 20 channels per group.

I think that is enough flexibility for us!

We can handle this in a couple ways:
1; board has two analog channels, one S/PDIF output (which may be same data on coax and optical), thats it.
2; same as above but one or more daugter card connectors to add additional outputs
3; multiple main boards with different numbers of outputs.

Adding extra analog outs (more DACs) is actually fairly easy. For example upping a Gen2 to 8 analog outs is not very difficult, the board costs more money becayse it has to be larger to support all those extra connectors! We could probably come up with a stacking connecter approach where you could stack multiple boards each with a set of jacks.

I would rather avoid optional outputs in a separate box, it gets difficult to maintain good clocking etc to external boxes (certainly not impossible, but difficult)

Of course any of this will require some way of getting multiple channel data into the box. Obvious first steps are things like Dolby Digital, multi channel encodded onto 2 channels, the encoder can run in software on the processor. Beyond that I think it will need a new or expanded protocol.

Any thoughts?

John S.

Triode
2013-01-30, 14:38
Is hdmi in or out of the picture ?

Not for streaming movies but for multichannel audio , this would also demand some small changes in the server to make it accept 5.1 and 7.1 FLAC and WAV (I mean 24bit lpcm over hdmi )

In many cases with a home cinema hdmi is all you need .

Maybe not for the audiophile as some hdmi implementations are horrific (not all ) , but I have no shortage of inputs so I use will use both :) (coax for stereo sound ) and I have the Meridian HD621 that copes with hdmi jitter problems (so they say ) .

My initial thoughts of hdmi are as a user interface for the player. Not for streaming to. I think 2 channel audio could be made to use this route, but multichannel will require significant changes to the playback app... (also is there enough multi-channel audio only material to justify this?)

Mnyb
2013-01-30, 14:56
My initial thoughts of hdmi are as a user interface for the player. Not for streaming to. I think 2 channel audio could be made to use this route, but multichannel will require significant changes to the playback app... (also is there enough multi-channel audio only material to justify this?)

Maybe not there is itrax that sells these as files or you rip your DVDA's it would be in the same domain as real 24/192 recordings .

Can it be 200-500 albums aviable ? The ripping would be a chore for sure .

That is a bit of a pity as the main advantage of DVDA and multichannel SACD over CD was discrete multichannel ( not the resolution) ,that's a difference you probably can hear .

But there is hope blue ray discs with music they are coming , DVDA aka MLP is resurected as Dolby true HD ( I think Meridan done a deal with Dolby to license as Dolby is very good at such things, and they have expanded the format even more , 8ch of 24/192 is possible ) .
But in this case maybe most will be happy playing the disc and not rip it blu ray ripping is unknown to me ?

w7r
2013-01-30, 15:43
We probably won't know the answer to this until we try. Or at least set up a list of pledgers.

For Gen1, it seems like a good idea to limit the number to 25.

For Gen2, I'd be interested in participating if you need any totally non technical folks.

I wish to provide as much encouragement as possible for this worthy initiative!

Regards,

Guido F.

Guys, I'm very happy to have found this thread, and echo guidof's post on this, cant help on the tech - way over my head but happy to be a "dummy" on the Gen2.

+1

I'll certainly be following this closely and good luck!

Cheers, chris

jmschnur
2013-01-30, 16:17
Get something simple working properly first. Then add HDMI and multichannel later. Do the design so that this path is possible.

I will be be very interesting in gen 2 testing and depending on status gen 1. Will there be a web site to sign up etc.


Joel

Mnyb
2013-01-30, 16:54
Get something simple working properly first. Then add HDMI and multichannel later. Do the design so that this path is possible.



I actually agree on that , I just wanted to spread the idea about multichannel , it would make for another difficulty in the server ,if you sync players it must either skip these tracks if using another 2ch player or downmix (possibly depending on platform ).

Multich and DSD and 24/192 , I think 24/192 will be in this .

DSD I suggest someone writes a server transcoder for that to pcm ,unless the magic chip John have found have this too ? (it seems very versatile)

simbo
2013-01-31, 01:56
4) Case design - norman12

I assume this doesn't cover the fabrication of the case too... anyone got a 3D printer? :)

simbo
2013-01-31, 02:01
DSD I suggest someone writes a server transcoder for that to pcm
I know GEN1 is going to be using the slimproto architecture, but if/when there is a desire to design a new architecture going forward, there's a danger that any work done now could be lost. I'd suggest sticking to the basics for the moment, unless they're confident it wouldn't be wasted effort.

JackOfAll
2013-01-31, 02:54
DSD I suggest someone writes a server transcoder for that to pcm, unless the magic chip John have found have this too ? (it seems very versatile)

Already exists. Before anyone else starts working on this, I already am. To the point where the files are imported to the library and then can be transcoded to native PCM using dsd2pcm (https://code.google.com/p/dsd2pcm/).



dff flc * *
# I
[dsd2pcm] 2 m 24 | [sox] -t raw -r 352.8k -s -3 -c 2 - -t flac -C0 - sinc -20k


The code to import into LMS library is very basic, although I should have the necessary code finished soon to import the tags from dsf files using perl Audio-Scan. More interesting is DoP (http://dsd-guide.com/sites/default/files/white-papers/DoP_openStandard_1v1.pdf), where via a transcoding plug the data can be "tunnelled" to a DAC capable of decoding it, allowing native DSD playback.

Gandhi
2013-01-31, 03:47
(First time poster, loong time lurker.)

My thanks to all involved for a great and very promising initiative!

I think the following premature detail would be useful for many of us Squeeople: an output for a power on/off signal to control an amplifier, perhaps just a +5V or +12V output when "on", for use with for instance a solid state relay.

A headphones out jack could be used instead together with an applet or plugin like PowerSwitchII (which I use), but I believe it's better not to hinder normal use of headphones.

Best Regards,
Gandhi

Not often enough well recorded and mastered CDs | dBPowerAMP with AccurateRip | FLAC | fanless ASRock Z77E-ITX Intel i5-3570T | Ubuntu 12.04.1 LTS 32-bit | LMS 7.7.3 | BruteFirDRC 3.0 | Transporter (balanced out) | Thule IA252B | Audio Physic Scorpio | no fancy cables. + Also some Booms. + Harmony 525s for them all, including waking the server from S3.

dustinsterk
2013-01-31, 07:11
Already exists. Before anyone else starts working on this, I already am. To the point where the files are imported to the library and then can be transcoded to native PCM using dsd2pcm (https://code.google.com/p/dsd2pcm/).



dff flc * *
# I
[dsd2pcm] 2 m 24 | [sox] -t raw -r 352.8k -s -3 -c 2 - -t flac -C0 - sinc -20k


The code to import into LMS library is very basic, although I should have the necessary code finished soon to import the tags from dsf files using perl Audio-Scan. More interesting is DoP (http://dsd-guide.com/sites/default/files/white-papers/DoP_openStandard_1v1.pdf), where via a transcoding plug the data can be "tunnelled" to a DAC capable of decoding it, allowing native DSD playback.

Very Cool! Nice work JackOfAll!!!

dustinsterk
2013-01-31, 07:13
(First time poster, loong time lurker.)

My thanks to all involved for a great and very promising initiative!

I think the following premature detail would be useful for many of us Squeeople: an output for a power on/off signal to control an amplifier, perhaps just a +5V or +12V output when "on", for use with for instance a solid state relay.

A headphones out jack could be used instead together with an applet or plugin like PowerSwitchII (which I use), but I believe it's better not to hinder normal use of headphones.

Best Regards,
Gandhi

Not often enough well recorded and mastered CDs | dBPowerAMP with AccurateRip | FLAC | fanless ASRock Z77E-ITX Intel i5-3570T | Ubuntu 12.04.1 LTS 32-bit | LMS 7.7.3 | BruteFirDRC 3.0 | Transporter (balanced out) | Thule IA252B | Audio Physic Scorpio | no fancy cables. + Also some Booms. + Harmony 525s for them all, including waking the server from S3.

+1 to this......I would look for a response from John but it seems like that should not be too hard.

Pascal Hibon
2013-01-31, 07:32
(First time poster, loong time lurker.)

My thanks to all involved for a great and very promising initiative!

I think the following premature detail would be useful for many of us Squeeople: an output for a power on/off signal to control an amplifier, perhaps just a +5V or +12V output when "on", for use with for instance a solid state relay.

A headphones out jack could be used instead together with an applet or plugin like PowerSwitchII (which I use), but I believe it's better not to hinder normal use of headphones.

Best Regards,
Gandhi


Another +1 on that.
I would go for the industry standard with 12 volt trigger output.

Secret Squirrel
2013-01-31, 08:07
I've been an avid user/lurker of the Squeezebox forums, and am very excited about this venture. I wish there was some way that I could contribute but I doubt there is. I'm definitely a "Jack of all trades" but importantly a "master of NONE".

I'd be a willing participant of GEN2. I can't image life without my squeezeboxen.

Best of all to you with the appropriate skills. I'll be following closely here on the forum.

SS

PS I was VERY sad when Slim Devices sold to Logitech and am VERY happy to see things heading in the direction you folks are headed!

PPS If some case pops up where I think I can help, I'll jump in. I do have computer skills but not on your level.

Mnyb
2013-01-31, 08:38
Already exists. Before anyone else starts working on this, I already am. To the point where the files are imported to the library and then can be transcoded to native PCM using dsd2pcm (https://code.google.com/p/dsd2pcm/).



dff flc * *
# I
[dsd2pcm] 2 m 24 | [sox] -t raw -r 352.8k -s -3 -c 2 - -t flac -C0 - sinc -20k


The code to import into LMS library is very basic, although I should have the necessary code finished soon to import the tags from dsf files using perl Audio-Scan. More interesting is DoP (http://dsd-guide.com/sites/default/files/white-papers/DoP_openStandard_1v1.pdf), where via a transcoding plug the data can be "tunnelled" to a DAC capable of decoding it, allowing native DSD playback.

Exactly except for DoP it would work on any current squeezebox :) cool project .

So no one has to do anything rigth now in the first gen of this player.

dsd2pcm is it cpu/memory hungry ? of some interest are any proper filtering applied to abide to scarlet book spec or more (like saracon ) you want to get rid of most of the ultrasonic chaff

pssc
2013-01-31, 09:13
Id like to make the case for 512MB having done a fair amount of hacking squeezeplay and Linux in general on the Pi 512MB has removed alot of pressure , I think we would thank ourselves for this later,

We could run s slightly less custom Linux and make use of dbus and associated daemons for network control, Bluetooth and avahi for service discovery moving froward,
Id think it would be advantageous to reuse other code bases for our non core functions ie music...

Phill.



Agreed and added.

GEN1:
1) Hardware design and implementation - JohnSwenson
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustinsterk (Me), eLR!C
3) Squeezelite Player - Triode
4) Case design - norman12
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) WIKI setup and updating for instuctional use of new device (from NON tech person(s)) - ?
7) Creation and setup of internal webserver configuration page hosted on OS of the device. - ?

GEN2:
8) Marketing/Name of the new product- (This is really for in the future but never to early to start thinking about it)
9) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - Cparker
10) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.) - ?
11) Localisation - eLR!C (French), mherger (German), epoch1970 (French)
12) Testing (Hardware, Software, etc) - ?

norman12
2013-01-31, 14:33
I assume this doesn't cover the fabrication of the case too... anyone got a 3D printer? :)

I wasn't going to bother designing anything for GEN1, I thought the dev guys could nail it to a plank of wood while working on it, although I'm happy to do so if needs be.

As for GEN2, my thoughts are along the lines of a standard aluminium extruded case with custom end panels - Nice thick CNC machined and engraved front panel and a laser cut and laser engraved rear.
I'm also thinking of producing a 3d model of a clam type case that people can take to their preferred rapid prototype supplier and get a set extruded - I'm not sure this would be any cheaper than the aluminium version though and cheap 3D printing looks a bit sh1t.

At this point I'm not sure what the board size will be and whether or not GEN1 and 2 will be identical in layout and connector placement. I did see 75mm square mentioned earlier in the thread (3" square to some of you guys). If it stays around this size we can make a lovely little case for it.

If we go for a standard extruded ali case we should make the board fit the slots often extruded internally - we would need 3mm clear of components and track running along the sides of the PCB to accommodate this.
Most of these extruded cases come standard widths and various lengths.
If the PCB could be made to fit the internal length as well as the width the mounted indicators, connectors etc would just pop through the end panel cutouts - no soldering, just slide in the PCB, 2 panels, 8 screws and 4 rubber feet later and you have a completed unit.

Both options could be obtained via a group buy and I'm willing to help with this if needed, but early days at the moment.

Once John has reasonably firm idea of the PCB area required I'll look see what is available off the shelf for the main case body.
Those who are interested pop over to the Hammond Manufacturing web site - they have a lot of info and 3D models of their standard range. These cases should be available worldwide from RS, Farnell and DigiKey amongst others.

norm

guidof
2013-01-31, 17:44
Agreed and added.

GEN1:
1) Hardware design and implementation - JohnSwenson
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustinsterk (Me), eLR!C
3) Squeezelite Player - Triode
4) Case design - norman12
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) WIKI setup and updating for instuctional use of new device (from NON tech person(s)) - ?
7) Creation and setup of internal webserver configuration page hosted on OS of the device. - ?

GEN2:
8) Marketing/Name of the new product- (This is really for in the future but never to early to start thinking about it)
9) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - Cparker
10) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.) - ?
11) Localisation - eLR!C (French), mherger (German), epoch1970 (French)
12) Testing (Hardware, Software, etc) - ?

I'm available to do localization in Italian and Spanish.

Guido F.

rgro
2013-01-31, 18:12
Wha..????? No Latin? No counseling and/or confessional for lapsed audiophiles??? You're slipping, Father Sarducci. ;>)


I'm available to do localization in Italian and Spanish.

Guido F.

eLR!C
2013-02-01, 00:17
Id like to make the case for 512MB ...
+1
We'll have enough trouble with initial kernel & scripts tests / tuning without loosing time on low memory limits at start :)

Pascal Hibon
2013-02-01, 01:40
Agreed and added.

GEN1:
1) Hardware design and implementation - JohnSwenson
2) Compiling OS/Building a bootable image/Writing automated scripts/Etc (this will break out much further in the future) - Dustinsterk (Me), eLR!C
3) Squeezelite Player - Triode
4) Case design - norman12
5) Distribution - ? (Depending if we need to ship to just one location and then send out to buyers from there)
6) WIKI setup and updating for instuctional use of new device (from NON tech person(s)) - ?
7) Creation and setup of internal webserver configuration page hosted on OS of the device. - ?

GEN2:
8) Marketing/Name of the new product- (This is really for in the future but never to early to start thinking about it)
9) Website Creation/Technical Hosting of files, scripts, news, shipping updates, product updates, etc. - Cparker
10) Licensing (looking into feasibility of signing up subscriptions services, radio services, etc.) - ?
11) Localisation - eLR!C (French), mherger (German), epoch1970 (French)
12) Testing (Hardware, Software, etc) - ?

If this project makes it to gen2, I want to volunteer for testing.
Many participants will be spread out over different countries in the world. Hopefully that is not a problem.

hsmeets
2013-02-01, 08:07
please ignore my ignorance...

would it not be better for a prototype to assemble such player from already available parts: a RpI or alike board, one of those A-sync USB to SP/DIF pcb's like that one from WaveIO (just to name one). Optionally a DAC. For operation, if the UI stays simple a LCD and a rotary encoder could be attached to the GPIO lines.

At least that is what I'm looking at for myself, as a hobby project, basically the main part missing (in my case) is some code to communicate with LMS about players status and command and code to display info and react to rotary encoder or IR input.

A more integrated approach, like attaching a DAC directly to the I2S bus (if the SoC provides) will involve some serious linux kernel hacking.

(I posted in the Squeezelite thread before I found this thread)

14405

JackOfAll
2013-02-01, 08:17
+1
We'll have enough trouble with initial kernel & scripts tests / tuning without loosing time on low memory limits at start :)

I don't think JS is going to budge on 256MB for GEN1 due to the additional layout complexity. As long as it doesn't get any less, (I think Erland said 128MB would be OK earlier in the thread, and I nearly choked on my coffee ;)), it will be OK. Having developed software exclusively for embedded devices for 5 years or so in a previous life, I know that the last thing you want to do is struggle for memory when you already have to accept the limited horsepower the CPU has to offer. (The idea of swapping to a SDCARD gives me the horrors.) 512MB would be nice and excessive for the stated purpose, but as long as it doesn't drop < 256MB, it'll be OK. There will still be wiggle room from a development and testing perspective.

JackOfAll
2013-02-01, 08:38
One thing I still don't completely understand is how important the USB really is if we:
1. Have a DAC that generally produce a better analogue out than everything else than high-end external DAC's
2. Have a S/PDIF that's significantly better than the Squeezebox Touch

Are all new external high-end DAC's USB only (without support for S/PDIF) or why is USB that important if we have an excellent S/PDIF and an excellent analogue out ?

One other thing to have in mind, is that while 192k is a practical limit for SPDIF, (typically less for optical), there are several USB UAC2 implementations now that support 384k. Whilst I'm not advocating big numbers for the sake of it, going forward I think we are going to see a lot more activity with DXD and DSD. Tunnelling DSD64 requires 176k4 PCM sample rate, DSD128 - 352k8.

I'm not an advocate of asynch USB for the sake of it, but always having been an advocate of clocking from the DAC side, asynch USB is important. John already stated that he didn't want to go for the two box solution, and working asynch USB UAC2 out sidesteps most of the downsides of a two box solution.

And whether I agree with it or not, the usual subjects (and by that I mean the mainstream audio press), have already held the wake for SPDIF, so going forward I think the high-end is going to migrate exclusively to asynch USB. That has started already.

To my mind, as far as future proofing goes, having a very good USB out is more important than the on-board DAC.

And to JS, if you are going to put an optical out on GEN2, please make sure you use a part that is capable of 192k, rather than the more usual 96k, even if it pushes the cost up a few bucks.

guidof
2013-02-01, 08:42
Wha..????? No Latin? No counseling and/or confessional for lapsed audiophiles??? You're slipping, Father Sarducci. ;>)

Nemo perfectus est.

Guido F.

simbo
2013-02-01, 09:01
I wasn't going to bother designing anything for GEN1, I thought the dev guys could nail it to a plank of wood while working on it, although I'm happy to do so if needs be.
I think GEN1 will need something, but I agree it doesn't have to be special, just functional.

erland
2013-02-01, 09:14
I don't think JS is going to budge on 256MB for GEN1 due to the additional layout complexity. As long as it doesn't get any less, (I think Erland said 128MB would be OK earlier in the thread, and I nearly choked on my coffee ;)), it will be OK.

For GEN1 we will be fine with less memory, it doesn't have any display and we don't plan to run a server on it during GEN1. The Squeezebox Radio which have a display have 64MB memory and the Squeezebox Touch have 128MB.

tcutting
2013-02-01, 10:33
What's the approach to power supply on this thing? Is the thought a wall-wart switching supply with good on-board post regulators for the audio section? Are there EMI concerns? How is the audio section going to be isolated from all the digital switching noise generated on the "computer" portion of the board?
Also was thinking about testing. Do these prototype boards get assembled at the fab/assembly house, and then sent out to the individual user without any form of functional test? That may be the only practical approach, as I doubt if John wants to perform a functionality check on even 25 boards.

Mnyb
2013-02-01, 10:52
A third party supplied wall wart would free John from CE and UL marking concerns and other oficial red tape .

Another way is in kit form ,when the kit is mounting your own power plug ;) on the cable , if an internal supply are considered .
( then its your own fault if the house burns down )

An internal supply would also make the box bigger and more expensive at least for a small series .

JohnSwenson
2013-02-01, 14:41
Lots of stuff to talk about here, some very good points raised, first power supply:

I'm thinking of a single 5V supply, such as for the Touch, on the standard connector. Thus a basic swither could be used or one of the aftermarket ones if desired. I would be glad to come up with one of my linear designs for this is which could be an option for it. At this point I have not done any research on the best wallwart to use with such a project, there are a lot out there, maybe after Gen1 boards go out different people can do some experimentation and come to some conclusions.

The grounding and noise issues etc are a very interesting aspect of this, what I am planning on doing is the following: the board will have two power domains, digital and analog. The digital domain has the processor, memory, ethernet, USB etc. The analog domain has the DAC chip, headphone amp, S/PDIF out, audio MCLK oscillators and reclocking flops. Each section will have it's own separate ground plane, with the few signals going between them going through isolators (I prefere the GMR types, I HATE ADUMS). There is a separate plane which just has the raw +5 and ground from the power supply, this plane connects to the two domains in one place for each domain. This scheme does a very good job of prevening digital domain noise from getting into the analog domain and still lets you power the whole thing off of a single supply. What makes it work is that there is one and only one ground connection between domains, this prevents any ground loops from happening.

Since I am planning on an eight layer board I can put signal routes between planes, which does a good job shielding, cutting down on EMI.

Cases: Norm you are right, I was just going to screw the Gen1 board onto a pice of plywood for my own use. I can certainly design it to fit a case if we can find own that works well. I want to keep the edge that has the connectors to 3" so I can get all the connectors on there.

I like the slide into extrusion concept, I have used it many times. One variaton I have done is use PCBs for the end panels, the board makers have the soldermask available in many different colors and silkscreen can handle labels etc. One interesting technique I use is to put holes in the soldermask so the underlying glold plating shows through, you can do logos, model name etc with this that REALLY look nice. I did one with blue solder mask and the gold showing through that was stunning. The price can be less than laser cut aluminum, and they can look quite striking.

Board testing: the manufacturing place I use automatically does bare board testing for multi layer boards to make sure the boards were done right. They also automatically do X-ray testing of BGAs to make sure the soldering came out right. They CAN do assembled board electrical testing. Simple testing is included in the price. They can do more extensive testing if test points are included on the board, but of course that costs more money. The big problem is that it takes a lot of time to come up with a good comprehensive test program. I don't think I want to do this for Gen1, but it's probably a good idea for Gen2. They have experts that will work with you to design a board that's easy to test. Again, probably not for Gen1, but probably a good idea for Gen2.

On the memory front, the AM3874 has two DDR controlers, so if we use two 256MB chips we get twice the memory throughput, it's tempting. My original thought was to limit the design to one memory chip since putting two chips on the same controller is MUCH more difficult. But since this processor has two controllers I don't have to deal with that, I can do two chips without the extra hassle. I think you guys have convinced me that it's probably worth doing it.

On the why do this in the first place? For me the motivation is that I can integrate quite good sound into the product for a LOT less money than it takes to do an equivalently good USB async DAC. The processors I'm looking at already have kernel drivers for audio over I2S and S/PDIF. These are available free from the manufacturer in their SDK which should make sending data to the DAC chip and S/PDIF not too difficult. Yes it is going to take some work, but I don't envision it being too bad.

That brings up the issue of other external interfaces (remotes, IR blasters etc). I'm kind of leary about putting those directly on the board. They WILL require kernel drivers to be written and frankly I'm not convinced that is going to happen.

I think we need to crefully look at this issue and come up with a workable solution so that separate kernel drivers do not need to be written for each interface. USB can be used for a large number of these, it might be a lot easier to come up with a GPIO over USB approach to add these. Anyway I'm not going to add these in Gen1, we as a community need to spend some significant time coming up with how to deal with this issue of other external world interfaces.

I hope that covered all the recent quations.

On another front, the BeagleBone is coming today, so hopefully I will have some results of hooking up USB DACs in the next couple days. There are SDcard images for at least 10 different distros for this board, it will be interesting to see what happens.

John S.

dasmueller
2013-02-01, 15:07
Great info. This whole project is very exciting ! Thank you for sharing all of your insights w us. And best of luck going forward.

vortecjr
2013-02-01, 17:07
John, I'm happy to you see you involved in this project. I received a call from a friend while driving home about this post and had some time to brain storm. I'm not a big fan of the one board fits all approach. I feel that having modules with the desired output allows one to optimize that output and you end up having a better product in the end compared to trying to put everything into one board.

The brains of the device (computer board) should be made as simple as possible with Ethernet input and USB and i2s output. The USB output is located on the same side as the ethernet connector and affords easy access to those who prefer a USB DAC or USB interface. The i2s output is located opposite of the ethernet and USB connectors and would used in combination with a module that would stack in the case. BTW the i2s output could be generated from a second onboard USB signal patch using a very good clock and clock power circuit. With this you now have the basic frame work to build anything! I can make available modules from my Rendu Network Player if you like the idea. I have an i2s to LVDS i2s output module that can be used with W4S and PS Audio gear. I have an i2s to Sabre analog output module with RCA output that can also be used to drive headphones. I can also make a tricked out SPDIF output module. Others can design modules as well...

Here are images of the modules;
i2s - http://www.sonore.us/Sonore-Rendu-i2s.png
Sabre - http://www.sonore.us/Sonore-Rendu-analog.png

Jesus R

JohnSwenson
2013-02-01, 22:55
I got the BeagleBone today, it's a nice little board. Well I'll cut to the chase, I plugged in the HRT Music StreamerII async, 24 bit UAC1, no hub. It works perfectly straight out of the box. No software tweaking at all, it plays perfectly, NO clicks, pops or any other problems. Looking at the stream file it shows it running in ASYNC mode S24_3LE and the momentary frequency DOES change. This seems to bode well for the hardware.

Next I'll try a XMOS based device, that is going to take a little bit more work to get setup (it's part of a DAC which is currently disassembled, I have to put it back together again before I can try it out).

I just plugged in the XMOS board and it seems to be working (until I get it connected back to the rest of the DAC I can't get any sound out of it). It shows it running in ASYNC with S32_LE and momentary freq is changing. Again it seems to bode well.

These were both at 44.1, it takes SOOOO long to transfer files to the SD card I haven't transfered over any 96 or 192 files. It does have sox so I can probably use FLAC to save some transfer time. Of course I need to get my music library mounted over the network, then I don't have to write them to the SD card.

I think that's all that is going to get done for tonight, I'll get the XMOS hooked up tomorrow and make sure it is actually playing music.

On another matter, the BeagleBone does have the I2S lines available on its expansion connector. It turns out that the distro it comes with has all it's module drivers available in /sys so parameters can be set. I found the driver for the audio interface (that handles both I2S and S/PDIF) in /sys, but there is no documentation on this and the node names were not exactly obvious. So it looks like it might be possible to configure the driver to send out I2s. I'm going to have to find the source for this driver in order find out what to put in the /sys nodes. So it might actually be possible to configure this to output I2S by just writing values to a /sys file.

John S.

Mnyb
2013-02-01, 23:31
Why 5v is it so that existing squeezebox power supplies can be reused ? Original or aftermarket . but is not a restriction ( possibly challenge ).

Pascal Hibon
2013-02-02, 02:00
John, I'm happy to you see you involved in this project. I received a call from a friend while driving home about this post and had some time to brain storm. I'm not a big fan of the one board fits all approach. I feel that having modules with the desired output allows one to optimize that output and you end up having a better product in the end compared to trying to put everything into one board.

The brains of the device (computer board) should be made as simple as possible with Ethernet input and USB and i2s output. The USB output is located on the same side as the ethernet connector and affords easy access to those who prefer a USB DAC or USB interface. The i2s output is located opposite of the ethernet and USB connectors and would used in combination with a module that would stack in the case. BTW the i2s output could be generated from a second onboard USB signal patch using a very good clock and clock power circuit. With this you now have the basic frame work to build anything! I can make available modules from my Rendu Network Player if you like the idea. I have an i2s to LVDS i2s output module that can be used with W4S and PS Audio gear. I have an i2s to Sabre analog output module with RCA output that can also be used to drive headphones. I can also make a tricked out SPDIF output module. Others can design modules as well...

Here are images of the modules;
i2s - http://www.sonore.us/Sonore-Rendu-i2s.png
Sabre - http://www.sonore.us/Sonore-Rendu-analog.png

Jesus R
While I have absolutely no idea how difficult it would be to implement the "Squeezebox protocol" on this board, I like the option of using modules very much. Such a platform would make upgrades and next gen players a lot easier to implement.

Are these modules that you have created yourself ?

vortecjr
2013-02-02, 06:17
I got the BeagleBone today, it's a nice little board. Well I'll cut to the chase, I plugged in the HRT Music StreamerII async, 24 bit UAC1, no hub. It works perfectly straight out of the box. No software tweaking at all, it plays perfectly, NO clicks, pops or any other problems. Looking at the stream file it shows it running in ASYNC mode S24_3LE and the momentary frequency DOES change. This seems to bode well for the hardware.

Next I'll try a XMOS based device, that is going to take a little bit more work to get setup (it's part of a DAC which is currently disassembled, I have to put it back together again before I can try it out).

I just plugged in the XMOS board and it seems to be working (until I get it connected back to the rest of the DAC I can't get any sound out of it). It shows it running in ASYNC with S32_LE and momentary freq is changing. Again it seems to bode well.

These were both at 44.1, it takes SOOOO long to transfer files to the SD card I haven't transfered over any 96 or 192 files. It does have sox so I can probably use FLAC to save some transfer time. Of course I need to get my music library mounted over the network, then I don't have to write them to the SD card.

I think that's all that is going to get done for tonight, I'll get the XMOS hooked up tomorrow and make sure it is actually playing music.

On another matter, the BeagleBone does have the I2S lines available on its expansion connector. It turns out that the distro it comes with has all it's module drivers available in /sys so parameters can be set. I found the driver for the audio interface (that handles both I2S and S/PDIF) in /sys, but there is no documentation on this and the node names were not exactly obvious. So it looks like it might be possible to configure the driver to send out I2s. I'm going to have to find the source for this driver in order find out what to put in the /sys nodes. So it might actually be possible to configure this to output I2S by just writing values to a /sys file.

John S.

John, the BeagleBone would seem to fit the bill very well. I have a buddy using it with hi res files and it's working out fine for him. Custom daughter cards would then provide all the needed outputs. My only concern would be the quality of the BeagleBone i2s signal..

Jesus R

vortecjr
2013-02-02, 06:43
Exactly except for DoP it would work on any current squeezebox :) cool project .

So no one has to do anything rigth now in the first gen of this player.

dsd2pcm is it cpu/memory hungry ? of some interest are any proper filtering applied to abide to scarlet book spec or more (like saracon ) you want to get rid of most of the ultrasonic chaff

The DSD2PCM conversion is done at the computer running Logitech Media Server. The conversion from DSD to PCM is easily done with something like an Atom processor for realtime playback. The filters are another story and the more filters you add the more CPU power you will need. When I tested this a few years ago I used a Pentium Dual Core processors with 4GB of RAM. SOX is being utilized in the script above to format the output and apply the lowpass filter that cuts the ultrasonic noise. I like to run additional filters, but this is up to the user...

Jesus R

Mnyb
2013-02-02, 08:20
The DSD2PCM conversion is done at the computer running Logitech Media Server. The conversion from DSD to PCM is easily done with something like an Atom processor for realtime playback. The filters are another story and the more filters you add the more CPU power you will need. When I tested this a few years ago I used a Pentium Dual Core processors with 4GB of RAM. SOX is being utilized in the script above to format the output and apply the lowpass filter that cuts the ultrasonic noise. I like to run additional filters, but this is up to the user...

Jesus R

Very cool , if you package this as plugin with sane settings for the filters ,I can not test as I have no such files , but I suppose my HP Microserver would have no problem . I turns SoX and Lame so then it could run this .

This type of file is the latest thing at the moment ,but I've never seen any music known to me come in this format ?

vortecjr
2013-02-02, 09:45
Very cool , if you package this as plugin with sane settings for the filters ,I can not test as I have no such files , but I suppose my HP Microserver would have no problem . I turns SoX and Lame so then it could run this .

This type of file is the latest thing at the moment ,but I've never seen any music known to me come in this format ?

Are there any SACDs that you like? Locked up in those SACDs is DSD data waiting to be ripped. Yes you need custom hardware to rip them, but many have and this is part of the reason for the format taking off.

There are also various player, such as HQ Player from Signalyst, that will up sample PCM to DSD to take advantage of the DAC's inherent Delta Sigma Modulation when converting to analog.

Jesus R

Julf
2013-02-02, 10:44
There are also various player, such as HQ Player from Signalyst, that will up sample PCM to DSD to take advantage of the DAC's inherent Delta Sigma Modulation when converting to analog.


Why is that better than letting the DAC do it internally?

vortecjr
2013-02-02, 11:23
Why is that better than letting the DAC do it internally?

Do you want a canned solution or do you want options? I like to have options...

Jesus R

Julf
2013-02-02, 11:30
Do you want a canned solution or do you want options? I like to have options...

So, if I understand you correctly, you are saying that one is not better than the other, they are just different - and having more choice is better?

JohnSwenson
2013-02-02, 12:00
Update on the BeagleBone, I got the XMOS based board connected to the rest of the DAC and sure enough it plays music when connected to the BB. Again no pops or clicks, it's running high speed UAC2 async without any problems.

That seems pretty definitive to me that this hardware can talk to modern high speed USB DACs and do it well.

Next I'm going to try Squeezelite.

John S.

Triode
2013-02-02, 12:16
Update on the BeagleBone, I got the XMOS based board connected to the rest of the DAC and sure enough it plays music when connected to the BB. Again no pops or clicks, it's running high speed UAC2 async without any problems.

That seems pretty definitive to me that this hardware can talk to modern high speed USB DACs and do it well.

Next I'm going to try Squeezelite.

John S.

Sounding good to me John - looks like I need to try to get hold of one too...

JohnSwenson
2013-02-02, 14:14
I got Squeezelite to run (armv6 version) everything works fine except there are some clicks every so often, particularly if I have "top" running I get a click every time it updates. I tried various -p options and it makes no difference, I also tried various -b options and again no difference.

BTW what is the arm "hf" version?

I checked with ps and didn't see any FIFO threads.

In general this looks good, USB Async works, up to 192 works, UAC1 doesn't need a hub. This is indicating to me that the processor itself is probably quite good enough for our needs. There may need to be some thread tweaking etc to get rid of the clicks.

I looked at /sys and it does look like it has the alsa driver that talks to the I2S,S/PDIF outputs. I have not found out how to configure and turn these on. I probably have to look at the source code to figure that one out. I'll spend some more time on that today.

So from my point of view staying with this class of processor seems good to me. I'm going to continue with the hardware design with the Ti processor. I'm probably going to go for the AM3874 rather than the AM3359 that is in the BeagleBone. The 3874 seems to have similar subsystems, so there is a pretty good chance it will work as well.

John S.

Triode
2013-02-02, 14:20
I got Squeezelite to run (armv6 version) everything works fine except there are some clicks every so often, particularly if I have "top" running I get a click every time it updates. I tried various -p options and it makes no difference, I also tried various -b options and again no difference.

BTW what is the arm "hf" version?

I checked with ps and didn't see any FIFO threads.

In general this looks good, USB Async works, up to 192 works, UAC1 doesn't need a hub. This is indicating to me that the processor itself is probably quite good enough for our needs. There may need to be some thread tweaking etc to get rid of the clicks.

I looked at /sys and it does look like it has the alsa driver that talks to the I2S,S/PDIF outputs. I have not found out how to configure and turn these on. I probably have to look at the source code to figure that one out. I'll spend some more time on that today.

So from my point of view staying with this class of processor seems good to me. I'm going to continue with the hardware design with the Ti processor. I'm probably going to go for the AM3874 rather than the AM3359 that is in the BeagleBone. The 3874 seems to have similar subsystems, so there is a pretty good chance it will work as well.

John S.

HF versions is hardfloat and is used if the distribution is using hardfloat calling conventions. This is used by Pi and other more modern linux distros as its faster to pass floating point parameters using this convention where the floating point registers are used. The soft float eabi passes float point parameters via the integer registers to remain compatible with cpus without floating point units. This used to be the default for all linux arm systems and is slower. Hence the migration to hardfloat as most machines now have floating point units.

Did you run squeezelite as root. The output thread is automatically created as sched_fifo if the user has permission to do this (which root has and you otherwise need to add the relavent permissions). Should see one thread as FIFO when you do this. Start with -d output=debug to see a log message indicating whether it was able to set fifo.

vortecjr
2013-02-02, 14:48
So, if I understand you correctly, you are saying that one is not better than the other, they are just different - and having more choice is better?

Julf, it's up to you and others to determine what is better, different or otherwise. I'm about options....without options there is nothing to compare...

Jesus R

JackOfAll
2013-02-02, 16:35
I got Squeezelite to run (armv6 version) everything works fine except there are some clicks every so often, particularly if I have "top" running I get a click every time it updates. I tried various -p options and it makes no difference, I also tried various -b options and again no difference.

Hmmm. That doesn't sound good to me. It sounds like the usual problems with trying to run UAC2 with non-ehci hardware. It's one thing fixing underruns and playing with thread priorities, another if the USB controller is generating too many interrupts for the proc to handle, or a crappy driver. ;) Linux UAC2 on the alsa side works perfectly with any XMOS device I have tried. When it doesn't, it's the USB driver side of things or hardware limitations.

Can you do the following......



echo 101 > /proc/asound/CARD/pcm0p/xrun_debug
echo 2 > /sys/module/snd/parameters/debug


You'll need to change CARD to be whatever your XMOS device is, either cardN, or by name.

After a few pops and clicks, dmesg, and see if you have anything logged. Let's see if we have XRUN's, or delay: estimated XXX, actual XXX.

Gandhi
2013-02-03, 03:29
...
So my question to everyone is simple......if there was a community funded project, would you invest your time? Would you invest monetarily? We all have different strengths and as a community I think we could really design one hell of a product.

Maybe I am wrong, but I truly do feel other users want to see this continue. If you do, please post what you would be willing to contribute.
...


I'm available to do localization in Swedish.

I would also be happy to make a monetary contribution. After all, this is a worthy cause.

As I presently have enough hardware to last a few years, I would primarily be interested in a more powerful 2nd generation (unless of course there will only be a 1st).

I don't consider myself to be especially price sensitive. I value sound quality, versatility and long-lasting build quality.

Gadgety1
2013-02-03, 04:23
I'm not sure whether we can turn this into a community product, but my personal view is that an effective Squeezebox replacement for the community can be made from a small existing arm based device + an external usb dac. This means all the audio engineering can be part of the dac and you can spend from $5 to $5000 based on your preference....

The device itself is probably based on something already available such as an android stick, raspberry pi or other such device - perhaps we need to settle on one or a small number of recommended devices and package for them. The one thing that most devices have now with hdmi, so a user interface using hdmi + control over that is probably required/sensible. This is not a mass market consumer product, but it gets us to a very viable solution for community enthusiasts... (and focusses much of the effort on software and packaging rather than hardware design and the necessary volumes this brings)

Squeezelite part of my steps in this direction. I'd like to look at UI solutions, perhaps integration with XBMC or alternative user interfaces hdmi - any takers?

Unsurprisingly this thread certainly seems to generate a lot of responses.

External DACs are not missing in the marketplace. In my view, what is missing from the marketplace is a wireless receiver that enables distributed sound, 24bits/96 khz or higher (which Sonos doesn't do), in the price region of the Squeezebox Touch, and with a variety of digital outs not just USB, but also S/PDIF coaxial, or even AES/EBU. A clock input and circuit wouldn't be bad either (although I guess that is a point of debate among audiophiles, when async protocols are used). The RPi, afaik, is limited to 11 bits, so would not be ideal base for an audiophile solution.

Software wise I believe integration with XBMC makes total sense because of the installed base, and for being community driven.

Gadgety1
2013-02-03, 04:34
Are there any SACDs that you like? Locked up in those SACDs is DSD data waiting to be ripped. Yes you need custom hardware to rip them, but many have and this is part of the reason for the format taking off.

There are also various player, such as HQ Player from Signalyst, that will up sample PCM to DSD to take advantage of the DAC's inherent Delta Sigma Modulation when converting to analog.

Jesus R

Seems the content has drifted slightly off topic on this thread, but as it has I'll respond. A lot of DSD-players are "outputting" PCM datastreams from DSD data, but only internally in the player. The DSD fad, 10 years after it's initial failure due to poor management by Sony, seems to be all the hype atm, driven by a need for differentiation by the up market audio companies, and money to be made. There's hardware available that takes advantage of this and outputs up to 6 channels of digital PCM audio. This one is for the Oppo players: http://audiopraise.com/vanity93/overview.php. The problem as far as I understand is to get these six PCM streams into the computer for ripping without buying expensive pro audio gear that requires a lot of active management in front of a PC screen.

vortecjr
2013-02-03, 06:22
Seems the content has drifted slightly off topic on this thread, but as it has I'll respond. A lot of DSD-players are "outputting" PCM datastreams from DSD data, but only internally in the player. The DSD fad, 10 years after it's initial failure due to poor management by Sony, seems to be all the hype atm, driven by a need for differentiation by the up market audio companies, and money to be made. There's hardware available that takes advantage of this and outputs up to 6 channels of digital PCM audio. This one is for the Oppo players: http://audiopraise.com/vanity93/overview.php. The problem as far as I understand is to get these six PCM streams into the computer for ripping without buying expensive pro audio gear that requires a lot of active management in front of a PC screen.

This conversation is relevant. You are just making generalizations without thinking things thru or researching them. Your kind of thinking is what limited the Touch and Transport to 96k and the Sonos to 44.1k. Your building a product here and you should IMO be pushing the envelope to attract as many people as possible. This product needs to support at least 384k to allow support for DSD128 via DoP. You need to support this not because you personally need it, not because of the "up market audio companies", not because of popularity, not because of available content, but because you can. BTW I have a running poll over on CA and so far 96.43% have voted that they want DSD support with there next purchase. Currently there are 45 products (up from 4-5 in just about year) in the market that support DSD. These products range from well priced to very expensive. Just about every computer audio player worth talking about supports high sample rates and DSD. There are a bunch of download sites that support hi-res and DSD downloads.

The way to get native DSD files from SACD is to rip them via a modified PS3. I don't know anyone recording digital from an OPPO:)

Jesus R

PS Here is a link to my DSD DataBase: https://docs.google.com/spreadsheet/ccc?key=0AgVhKcl_3lHfdFVyenBBNjNpQ2lieG81WGpqQTNfV UE#gid=0

JJZolx
2013-02-03, 06:32
My 2¢: I couldn't care less about DSD support. Or even 192 kHz, for that matter.

Julf
2013-02-03, 06:48
You need to support this not because you personally need it, not because of the "up market audio companies", not because of popularity, not because of available content, but because you can.

I can think of a gazillion features you *could* support. Does it mean they should be supported, just because you can? Of course not.


BTW I have a running poll over on CA and so far 96.43% have voted that they want DSD support with there next purchase.

Sorry, but "DSD is the new vinyl" is one of the dogmas on CoA that you simply have to agree to to be part of that forum. It proves absolutely nothing about the rest of the world.


There are a bunch of download sites that support hi-res and DSD downloads.

And how many recordings are there currently available in native DSD (as opposed to DSD converted to PCM)?

vortecjr
2013-02-03, 06:49
My 2¢: I couldn't care less about DSD support. Or even 192 kHz, for that matter.

I don't have a problem with that and I respect your needs, but your missing the point. You are covered at whatever rate floats your boat if you build in the bandwidth...

Jesus R

Julf
2013-02-03, 06:49
My 2¢: I couldn't care less about DSD support. Or even 192 kHz, for that matter.

+1