• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required. There are many reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

ASR Open Source Streamer Project

voodooless

Grand Contributor
Forum Donor
Joined
Jun 16, 2020
Messages
10,403
Likes
18,364
Location
Netherlands
@Skeptischism , do you also plan to have some kind of input as well? SPDIF would be great to have so you can hookup external sources. The best would be to keep it in sync with the DAC using an ASRC. In that case, the whole DSP solution can do without sample rate conversion in software.
 

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
most likely, but dont know what chips, now that the AKM stuff is off the table. I can score some for my own purposes, as I have with the ADCs, but for a product its a different story. in the case of xmos USB, any async spdif would happen through there. I do think its possibly more powerful to do it in linux, but upsampling/OSF etc performed after XO would save on resources, vs running camilla at 352khz or whatever.
 

voodooless

Grand Contributor
Forum Donor
Joined
Jun 16, 2020
Messages
10,403
Likes
18,364
Location
Netherlands
Cirrus comes to mind: CS8416 and CS8421
 

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
oh I know the usual subjects; just hadnt really thought about it much lately, since its not overly important to me. I'll have some sort of bluetooth input as well, which is a whole nother story. maybe any wireless is best handled by the ROCK, wifi etc to interface with phones and tablets for content. having an embedded computer throws a bunch of possibilities; its more a matter of culling them.
 
Last edited:

voodooless

Grand Contributor
Forum Donor
Joined
Jun 16, 2020
Messages
10,403
Likes
18,364
Location
Netherlands
oh I know the usual subjects; just hadnt really thought about it much lately, since its not overly important to me. I'll have some sort of bluetooth input as well, which is a whole nother story.

Why? The streamer should do Bluetooth ;)
 

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
see my edit :) the bluetooth module would be sans embedded pc. plus they (prebuilt bluetooth SOC modules) are sometimes the easiest way to access the better codecs, without licensing them yourself. same goes for emissions testing
 

phofman

Addicted to Fun and Learning
Joined
Apr 13, 2021
Messages
502
Likes
326
Skeptischism: In my question regarding the clock I did not realize that this SoC has (multiple) MCLK inputs and can generate all I2S signals on demand from the MCLK input as required, with appropriate MCLK/BCLK ratio as supported by your DAC for the given samplerate (register I2S_CKR on page 710 of http://opensource.rock-chips.com/images/e/ee/Rockchip_RK3399TRM_V1.4_Part1-20170408.pdf ). That is very convenient, a single XO will likely do for one samplerates family (IMO no reclocking required when the MCLK feeds the DAC directly).

I am working on a CM4-based project with the dumb BCM2711 where I have to provide MCLK + BCLK (+ LRCLK) on my own (+ different MCLK ratios for DAC and ADC) which requires a clock generator with at least 3 outputs with configurable dividers - that's why I was asking about the clock circuit. The Rockchip is much more user-friendly indeed, having all the configurable dividers integrated.
 
Last edited:

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
yes, I saw the bunch of i2s clockdiv and clock input and sync and hadnt looked through the details of how that plays out; but it did raise a smile based on my hopes of what they meant and open my wallet :). saving that reading for another day, but thanks very much for the confirmation.

I still have to worry about them for the project as a whole though that may not include a streamer, but it is looking good and has utility/performance only surpassed by a dedicated MCU and FPGA and I suppose they will provide a decent point of reference for that too. thus, I still need the separate module for my own needs. it depends on the particular dac, but those that are clocked on MCLK (like just about every modern dac is), I wouldnt think more reclocking would be needed, depends on the PCB and connector quality (2.54mm pinheaders arent ideal) and jitter caused by the logic drivers internal to the chip. likely transparent enough for all but neurosis level fussing.
 

phofman

Addicted to Fun and Learning
Joined
Apr 13, 2021
Messages
502
Likes
326
IMO if the conversion stage of your DAC is clocked by the MCLK (which is mostly the case for regular sigma/deltas), no pinheaders, logic gates, and long PCB traces should be in the path as your MCLK clock can sit right next to the DAC chip.
 

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
they arent, but there is on the board that isnt in my control, the ROCKpro64, thus mentioning them. this isn't my first rodeo :) even if a ribbon cable or something is used to byass that connector, there is a serious lack of ground pins. they provide all these i2s pins, but ive seen no mention of accompanying ground pins.
 
Last edited:

phofman

Addicted to Fun and Learning
Joined
Apr 13, 2021
Messages
502
Likes
326
OK, I thought the MCLK would be provided by your board, not generated by the RK. Whatever your plan, you will do fine, that's sure.
 

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
ha, sorry, crossed wires I think here somewhere. in prototype stage, although I will have a placement for mclk on the board, it ill probably not be populated initially. I will have a separate board, which will have control and clocking, MUX etc, with I/O logic. this has SMA, as does the dac board next to its clock. the other signals optionally ufl, or FPC cable.

this functional block will either remain as a separate entity, with an onboard clock that can be used, or, if it proves to actually result in lower jitter to have the XO right next to the dac, vs a little distance away, likely in a shielded can, connecting with shielded SMA. that way the local clock can be active for the use case with streamer and multichannel i2s direct, or not populated/output disabled for other use cases. I was toying with the idea of LVDS, but I think i'll stick to single ended. it will likely relocate to the main board in a more final form (for my project). I want to test that circuit out by itself and also use for other projects like a measurement preamp and phono input ADC etc etc. I have some AK5394 i'm going to make use of for those builds.

now to see if I can work out where you are at, without going to look at the documents again. are the i2s clocks/logic gates internal to the PINE ROCKPRO64, available on the pinheader, able to be driven by an external master clock? including multipliers/dividers, all synchronous to that master, yes?
 

Jungstar

Active Member
Joined
Apr 7, 2019
Messages
116
Likes
39
I'm somewhat new here, I'm an economist and not an electrical engineer, but I did "build" a few RP players. I mostly use Spotify and Volumio. I wanted to add my 2-3 cents of input, as I would love to see this project succeed.

1) My biggest issue is still stability and usability. Basic stuff, like can my spouse also connect and use her iPhone to play. Can she also connect her Spotify account? (something Amazon Alexa has not fixed last time I checked). Or, If the internet dies or is spotty, can we turn down the VOLUME.
I also often experience "small lags" or puffs or sounds when changing tracks. I also experience lag. Being a user of a top-notch PC on a daily basis, I'm NOT used to waiting for the interface to react. On forums, I see similar issues for Moode and Volumio.

2) Wishing for features is easy. Another is the willingness to pay for them and understanding limitations or added complexity. I think starting with a price point would be healthy. It forces priority. A 200 USD DAC Streamer and a 450 USD DAC Streamer are very different targets. If we are going to suggest features, I would suggest a "log/board", where people can post images and headings of existing solutions, it is much easier to browse than text all over the place.

3) Decision-making I would almost suggest engaging a few "nerds" from the DIY community forum. Maybe even make a design competition. We could raise some money and ask for well-thought proposals. Then we don't need to discuss 8 channels cs 2 channels vs adding multiple DACs or what kind of DSP we want etc. Vote in the end. Nr 1,2,3 would get some prize money. Maybe even 2 versions get funded and created. There are a few people that are already designing stuff like Ian (Canada) and running limited Group buys. I think their input would be valuable.

Just my 2-3 cents :)
 

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
you are talking to nerds from DIYAUDIO (some of the nerdier nerds, even) :). at least 3 participants in this conversation over the last few pages.

1 and 2, i'm with you, although this isnt the development thread proper I wouldnt think, at this point. I'm already doing what i'm doing, but it sounds like a good idea if you want to turn it into a much wider project, perhaps. We have made a pretty good start on the wants and needs, but it needs more work for sure. although I wouldnt want to put in a bunch of time and then have the design not used for whatever reason, as I would think most semi-pros and pros, with limited time available to them. It depends on the prizes I guess ... lol!!! It does sounds a bit like design by committee and that almost never turns out well in my experience. better to designate leaders for different sections and work together towards a goal, once objectives and limits are discussed and decided. Thats my POV anyway. a project page could be started here in a thread, with a mud map and collected ideas, or set up a project at github

Ians stuff is good, but no reasonable current multichannel solution, is all Rpi based as well and that has no multichannel i2s (which weve discussed in detail here). He has no multichannel dacs and his 2 channels are not really set up that well for ganging together. Ive been following his project for years. It does cause o.5 seconds delay minimum, higher in lower sample-rates, by its nature, so sync with streamed video is a problem, if that is important to you.

It also isnt cheap, when all bits are added together, along with multiple power supplies and power supply/ground domains, battery boards etc etc. youve just pushed the price well over $500 all told, for 2 channel, without a case and opened a pandoras box of too many options for everything and a bit of a learning curve for setting it up, for the less experienced. It is a lot of resources spent on jitter, too IMO, which, past a reasonably easily achieved level, I think is the least important aspect.. Its relatively easy to achieve jitter in the low ps range without large FIFO buffering. actual measured analogue conversion quality of his dacs is easily matched (bettered) with any number of available solutions, they are simple, well laid out, but do not have onboard regulation AFAIK, since he favors batteries and supercapacitors. So you have to add your own power supply, or use his somewhat involved and physically large arrangement. He is the first to admit hes not an expert dac designer (he is a very humble man) and the dacs themselves are simple; it is the surrounding circuitry to provide isolation, control and clean i2s signals to his, or other designs that is where his focus lies. hes a fan of class A and his main dac uses transformers for IV conversion. linearity isnt what they are designed for (SINAD is likely to be underwhelming and not a design goal); although he does offer a simple but likely well performing opamp based IV stage as well.

his controller board and all PCBs in general are very well designed, the buffer and its peripherals do what they say on the box and very well, but there are some gotchas.

BTW, Volumio is supported on the ROCKPRO46 boards we have been talking about and it is a more powerful board than Rpi4, with more possibilities for onboard SSD etc.
 
Last edited:

Skeptischism

Active Member
Joined
Sep 6, 2019
Messages
229
Likes
124
For power supply, I would suggest selecting a well designed switchmode supply (with recommendations for each country) and post regulating that for the low noise analogue sections. this sidesteps some of the more difficult and expensive to pass regulations that come with AC power; as your switcher will already have the proper approvals. that way builders only ever have to deal with properly isolated low voltage DC.
 

Jungstar

Active Member
Joined
Apr 7, 2019
Messages
116
Likes
39
you are talking to nerds from DIYAUDIO (some of the nerdier nerds, even) :). at least 3 participants in this conversation over the last few pages........

Great to we have a lot of DIY nerds... Well, I'm excited... I don't know Ian's products in detail - he just seems like someone with higher ambitions than Hifiberry etc.
Some project board where ideas for each unit (input, output, supported players etc, screen vs headless vs I2c would make it easy to for people that have not read through all 20 pages to contribute. I also don't know if someone has developed a product here before in cooperation. I'm also unaware, who owns the IP once it is done?
 

Balle Clorin

Major Contributor
Joined
Dec 26, 2017
Messages
1,347
Likes
1,219

mkarikom

Member
Joined
Jun 2, 2020
Messages
73
Likes
45
2. End-point support for Roon and Airplay. You call can suggest others.

I'm very excited about this project, in general.

I'm not a Roon user, but when I was considering their service, it always bugged me is that they have seemingly gone out of their way to prevent WAN access. Yes, the performance of Roon over an internet connection would be less consistent, but that's easy to explain in the service documentation.

Given the fact that many people can now configure a home VPN with little or no networking expertise it would be cool to design this streamer with 'dad-friendly' vpn client configuration, or at least design the UI and hardware to support a networking module.
 

voodooless

Grand Contributor
Forum Donor
Joined
Jun 16, 2020
Messages
10,403
Likes
18,364
Location
Netherlands
For what purpose would you need Roon via WAN or a VPN?
 
Top Bottom