Hi sveia,
Thanks for your offer, I wasn't aware another usb interface was in development. Do you gave a forum or a website? I guess the board is quite expensive, it looks quite complex. I guess we are trying to get a more stripped down solution, mainly the interface only, capable of 192/24 or 32 asynchronous and then play with our DAC's and PSU's.
@sampler
One member of the development team for the widget was entailing your concerns regarding windows drivers, check this out:
There are problems with Windows USB Audio drivers:
(1) Limited to UAC1, no UAC2 support;
(2) Async OUT with rate feedback reported to work only in Vista (but not at 192khz). Does not work in WinXP at all. Don't know whether works in Win7. Win7 has worse ISOCHRONOUS performance than Vista so may have big problems at high sampling rates.
So big manufacturers bypass Windows UAC completely and write custom drivers, using USB bulk transfer. In fact, I am writing a version of the widget firmware using bulk transfer as well.
UAC2 is the way forward. However, it is only supported in Linux (kernel 2.6.35 or later) and Mac OSX (snow leopard) only. For Windows, there are commercial UAC2 drivers from several companies. However, those drivers cost $$$, and works only for simple audio devices, not for composite devices.
With UAC1, there is no known solution for the UC3A3 to get to 96khz or beyond. I figured out that it might be possible to do it with AP7000 Basically you need max EP size of > 512 bytes, and/or multiple transactions per uFrame. Both options not supported by UC3A3.
Oh, and by the way, can you confirm I am corectly calculating the following?
Supose I want to know the transfer rate needed for streaming 192Khz / 24 bit. Would this be, 192000 * 24 / 8 = 576 000 bytes?
Because I've seen one person mentioning that: For AT32UC3A3 device, as it supports high speed USB, it can support 88.2 and 96khz sampling rate with 24 bit. But for higher sampling rates such as 176.4 and 192khz with 24 bit stereo the USB end point can not support the number of bytes required(1152 for 192khz,1059 for 176.4) for every millisecond. Because the USB end point can support at the maximum 1024 bytes for AT32UC3A3. But for the I2S, it should be possible to output 192khz sampling rate.
For some reason, I get half the value the person above gets.. Are there only 4 bits in one byte instead of 8?
Thanks!
Thanks for your offer, I wasn't aware another usb interface was in development. Do you gave a forum or a website? I guess the board is quite expensive, it looks quite complex. I guess we are trying to get a more stripped down solution, mainly the interface only, capable of 192/24 or 32 asynchronous and then play with our DAC's and PSU's.
@sampler
One member of the development team for the widget was entailing your concerns regarding windows drivers, check this out:
There are problems with Windows USB Audio drivers:
(1) Limited to UAC1, no UAC2 support;
(2) Async OUT with rate feedback reported to work only in Vista (but not at 192khz). Does not work in WinXP at all. Don't know whether works in Win7. Win7 has worse ISOCHRONOUS performance than Vista so may have big problems at high sampling rates.
So big manufacturers bypass Windows UAC completely and write custom drivers, using USB bulk transfer. In fact, I am writing a version of the widget firmware using bulk transfer as well.
UAC2 is the way forward. However, it is only supported in Linux (kernel 2.6.35 or later) and Mac OSX (snow leopard) only. For Windows, there are commercial UAC2 drivers from several companies. However, those drivers cost $$$, and works only for simple audio devices, not for composite devices.
With UAC1, there is no known solution for the UC3A3 to get to 96khz or beyond. I figured out that it might be possible to do it with AP7000 Basically you need max EP size of > 512 bytes, and/or multiple transactions per uFrame. Both options not supported by UC3A3.
Oh, and by the way, can you confirm I am corectly calculating the following?
Supose I want to know the transfer rate needed for streaming 192Khz / 24 bit. Would this be, 192000 * 24 / 8 = 576 000 bytes?
Because I've seen one person mentioning that: For AT32UC3A3 device, as it supports high speed USB, it can support 88.2 and 96khz sampling rate with 24 bit. But for higher sampling rates such as 176.4 and 192khz with 24 bit stereo the USB end point can not support the number of bytes required(1152 for 192khz,1059 for 176.4) for every millisecond. Because the USB end point can support at the maximum 1024 bytes for AT32UC3A3. But for the I2S, it should be possible to output 192khz sampling rate.
For some reason, I get half the value the person above gets.. Are there only 4 bits in one byte instead of 8?
Thanks!
Stereo you say, hmm, interesting 
Just want to report the ElectrArt USB-Dual-Audio is another *reportedly* Asynchronous USB i2c interface. pretty pricey compared to most of the options talked about already at around $300, though it has DSD support I/O. Just started playing with mine, sounds excellent so far with PCM sources, even better with DSD, still yet to compare to the i2c modified esi juli@ running the buffalo-II.
Do you have hear C-Media CM6631? Onkyo has use this chip in their P-3000R. Its seems that had full support UAC2 and has async OUT with rate feedback reported. It can support sample rate 192k/96k/88.2k/48k/44.1k 16/24/32 bit. It also provided Windows XP/Vista/Win7 WDM/ASIO driver. You find Onkyo P-3000R introduction in follow URL http://www.intl.onkyo.com/downloads/product_info/pdf/p-3000r_eu_leaflet.pdf
Sorry I can't give you the datasheet. You need contact to C-Media's sales.
Why you need CM6620? CM6620 don't support I2S interface. AS I know it just like a USB to HDAudio bridge. Becase it's use 2 chip one is HDAudio codec and the other is CM6620. CM6620 also don't support feedback endpoint. Only CM6631 can support feedback for async transfer.
I think you should contact to C-Media's sales for detail.
Multi-Channel Asynchronous USB to I2S Interface
I’ve just started a thread on a new design for 8-channel Asynchronous USB to I2S interface. Please have a look: http://www.diyaudio.com/forums/digi...i-channel-asynchronous-usb-i2s-interface.html
Any feedback is highly appreciated.
exa
I’ve just started a thread on a new design for 8-channel Asynchronous USB to I2S interface. Please have a look: http://www.diyaudio.com/forums/digi...i-channel-asynchronous-usb-i2s-interface.html
Any feedback is highly appreciated.
exa
I just discovered this thread today and tried to read every posting. Whew!
I think that many people have already listed the exact features that I would want, but I still feel a need to reiterate what I think would be ideal, and ask a few questions.
My first reaction upon hearing about the idea of a DIY player is that it would be great if there were a standard interface between the decoder (uC) and converter (DAC) boards. I2S seems like a great candidate, so a standard built on that might allow the larger community of DIYers to mix and match different DAC boards with the same interconnect.
My Requirements:
1) Single-chassis design with at least three boards: power, decoder, converter
2) No PLL, no SPDIF input, no HDMI input, no external Word Clock, no slaving to USB or FireWire or other interface. i.e. clocks should not originate outside the chassis.
3) Minimum 24-bit 192 kHz stereo
4) Standard I2S interconnect for up to 8 channels of I2S at 24/192 between the internal boards, ideally placed at the edge of the boards for minimal distance and shortest connections
5) Standard power connectors (if possible) so that off-the-shelf power boards can be used instead of DIY everything
Options:
The standard internal interconnect could be designed to allow the clock to originate on the decoder or converter boards. High-end DAC boards with clock generators could ignore the clock from the decoder and send back its locally-generated clock to the decoder. Less-expensive DAC boards could loop back the decoder clock via a short trace. In either example, the decoder would slave to a clock, whether it's generated on the decoder board or the converter board.
The decoder could be fed by UPnP over Ethernet, Async USB-Audio, or FireWire Isochronous Audio. Local access to storage devices like CompactFlash or USB Drive would be handy.
Questions:
How much difference does LVDS make in terms of sending I2S bit clock and word clock between two boards inside a shared chassis with a shared power supply? If LVDS is essential, then design a standard ribbon or FFC wiring pinout and start designing boards.
Would it really make things any easier to have a standard interconnect for I2S with a common pinout? What are people doing now? Are they soldering individual wires between boards for I2S connections? Are there any disadvantages to that approach?
Is it possible to design a pinout that could either have a dedicated ground for each signal -or- a differential pair for each signal? If so, would it then be possible to mix and match LVDS and single-ended signalling? Obviously, a single-ended receiver could not connect the individual signal grounds to true ground because there might be a differential transmitter on the other board, but I think this might be workable, if there is any advantage to creating a highly-adaptable standard interconnect.
I2S sometimes involves a return data line, from the DAC to the uC ... would this be necessary in the standard to allow for some DAC options?
Comments:
Personally, I'd like to see a snazzy Hirose flex connector of a specific pin count, with very short Flat Flexible Cable interconnects. That would make it a cinch to connect a decoder board to a DAC board.
With such a standard, it seems that we would not be limited to USB-to-I2S for the decoder, but could also have Ethernet UPnP-to-I2S or for the really adventurous: FireWire-to-I2S using Isochronous Audio.
Folks who are concerned about discrete I/V could design a converter board with a current-output DAC chip and then plug any variety of DIY I/V boards after that, while others could just choose an all-in-one converter board with voltage-output DAC. Once you have I2S, the details of the DAC output are flexible.
I believe that 8-channel I2S would be easy with 4 data lines and just a single pair of shared bit clock and word clock lines. LVDS would double the pin count, but it could still be manageable.
I think that many people have already listed the exact features that I would want, but I still feel a need to reiterate what I think would be ideal, and ask a few questions.
My first reaction upon hearing about the idea of a DIY player is that it would be great if there were a standard interface between the decoder (uC) and converter (DAC) boards. I2S seems like a great candidate, so a standard built on that might allow the larger community of DIYers to mix and match different DAC boards with the same interconnect.
My Requirements:
1) Single-chassis design with at least three boards: power, decoder, converter
2) No PLL, no SPDIF input, no HDMI input, no external Word Clock, no slaving to USB or FireWire or other interface. i.e. clocks should not originate outside the chassis.
3) Minimum 24-bit 192 kHz stereo
4) Standard I2S interconnect for up to 8 channels of I2S at 24/192 between the internal boards, ideally placed at the edge of the boards for minimal distance and shortest connections
5) Standard power connectors (if possible) so that off-the-shelf power boards can be used instead of DIY everything
Options:
The standard internal interconnect could be designed to allow the clock to originate on the decoder or converter boards. High-end DAC boards with clock generators could ignore the clock from the decoder and send back its locally-generated clock to the decoder. Less-expensive DAC boards could loop back the decoder clock via a short trace. In either example, the decoder would slave to a clock, whether it's generated on the decoder board or the converter board.
The decoder could be fed by UPnP over Ethernet, Async USB-Audio, or FireWire Isochronous Audio. Local access to storage devices like CompactFlash or USB Drive would be handy.
Questions:
How much difference does LVDS make in terms of sending I2S bit clock and word clock between two boards inside a shared chassis with a shared power supply? If LVDS is essential, then design a standard ribbon or FFC wiring pinout and start designing boards.
Would it really make things any easier to have a standard interconnect for I2S with a common pinout? What are people doing now? Are they soldering individual wires between boards for I2S connections? Are there any disadvantages to that approach?
Is it possible to design a pinout that could either have a dedicated ground for each signal -or- a differential pair for each signal? If so, would it then be possible to mix and match LVDS and single-ended signalling? Obviously, a single-ended receiver could not connect the individual signal grounds to true ground because there might be a differential transmitter on the other board, but I think this might be workable, if there is any advantage to creating a highly-adaptable standard interconnect.
I2S sometimes involves a return data line, from the DAC to the uC ... would this be necessary in the standard to allow for some DAC options?
Comments:
Personally, I'd like to see a snazzy Hirose flex connector of a specific pin count, with very short Flat Flexible Cable interconnects. That would make it a cinch to connect a decoder board to a DAC board.
With such a standard, it seems that we would not be limited to USB-to-I2S for the decoder, but could also have Ethernet UPnP-to-I2S or for the really adventurous: FireWire-to-I2S using Isochronous Audio.
Folks who are concerned about discrete I/V could design a converter board with a current-output DAC chip and then plug any variety of DIY I/V boards after that, while others could just choose an all-in-one converter board with voltage-output DAC. Once you have I2S, the details of the DAC output are flexible.
I believe that 8-channel I2S would be easy with 4 data lines and just a single pair of shared bit clock and word clock lines. LVDS would double the pin count, but it could still be manageable.
At last this thread is developing fast, very good
But lets not get over our selfs, shall we ?
At this point we are just considering all options, no decisions are made, so no purpose of count me in/out game, just constructive discussion.
Eric has visualized for us what really can be called "ultimate" I2S source, if done right. As previous GB perfectly showed, such product (basically just the uC part) is almost impossible to acquire.
[ ...]
For reaching some kinda consensus on global design, I personally don't see what this fuss is all about. If Erics block scheme goes to pcb, it's already way ahead of all currently commercially available products for USB to I2S (spdif) that I'm aware of.
[ ...]
EUVL idea of dividing this PCB to separate modules is very good and worth considering IMHO. This concept would have all the advantages that Eric has already named. Biggest drawback I think would be increased overall price for buy&forget people and maybe somehow decreased performance (it is integral part of modulus design).
I see another drawback to the module approach vs the integrated board approach.
We are DIYers with differing needs. Yet, we are not a huge group and are already struggling with licensing costs, etc. So, the best way to combine the divergent needs with the unanimous need is to create one board only, and have everyone interested buy into that one board.
Economies of scale, economies of effort. People who do not want exactly the same thing none the less will help each other by buying the same board, amortizing costs to the maximum possible beneficial level for all.
The disadvantage may be speed of development. However with everyone having a stake, it should get done reasonably quickly, since people may be inclined to help in areas where they otherwise would not be inclined to help if a small board offers all they need.
I see no need to have power supplies integrated. There are a hundred existing supplies to use so everyone, regardless of effort, can solve that.
If the "buy and forget" people are buying the same board, we leverage that money and lower costs. Otherwise they buy nothing, or buy something else, but do not help pay down the cost of the module in either case. it could easily end up cheaper than a separate USB-I2S module board alone that is not as popular.
Arduino does nothing ... absolutely nothing ... that has not been done before a hundred ways. But because it is just enough, everyone uses it. Same thing here.
Last edited:
I think you will need to define exactly what you mean by "one board only." Personally, my impression is that if your one board includes the DAC, then it will be impossible to satisfy everyone. There are already many DIY boards here, and each DAC can be vastly different (SRC, NOS, etc). If the board includes the DAC, then even among the group here, the interest will be too small.
Another personal preference is that I do not want to buy a potentially overpriced standalone DAC product and then modify it with USB-to-I2S. That's a great path for some, but I would prefer to buy or build a bare DAC board and plug it in to the USB-to-I2S (or UPnP-to-I2S or FW-to-I2S). That's why I suggest a common pinout for a DIY-standard interconnect between I2S devices, unless folks think soldering individual wires is acceptable.
The comparison to Arduino is pertinent, because it has a standard pinout for daughter boards. I submit that the reason Arduino is so popular is that most people buy a pair of boards: The Arduino itself, plus a specific daughter board for their application. If you're interested in the same success as Arduino in the DIY Digital Source category, then I think we need to define a standard I2S connector.
I have already proposed a ribbon connector on the Dangerous Prototypes forum, where a fellow 'brian' pared this down to a 10-pin version. The proposal supports both single-ended and LVDS signals, since I get the impression from reading diyAudio that differential is a potential benefit.
I agree that it's prudent to consider the "buy and forget" people, but how many of them will buy a bare board without an enclosure? I assume that the "buy and forget" category will expect to be delivered an enclosure where the wires and chips are safely hidden away. I my assumption is correct, then why would they care about the details if there happen to be two boards inside?: a USB-to-I2S and a DAC?
In other words, I think this is a bit of a Catch 22.
...
I am one of those experience embedded programmers, although I probably will not have much time to donate on such a non-trivial task.
I wanted to clarify the assertion that "the uC is almost impossible to acquire." The deal here is that there are a couple of categories of chips. Some chips, most notably the FTDI Chip line, are pre-programmed for particular USB tasks. In that category, it is almost impossible to acquire a USB-Audio chip that works as needed by the audiophile community. But the other option is a programmable uC with a USB peripheral. These uC chips are easy to obtain, and there are many options available. As you say, though, such a uC requires programming. So, it's not the uC that is impossible, but finding firmware. The market for completed USB-Audio firmware is possibly as high as $50,000 (unless those are just wishful high bids), and I assume this includes the customization needed for a specific uC. Wavelength Audio might have a finished firmware solution, but I don't know whether Gordon is willing to sell to anyone but Ayre (I'm recalling a recent Stereophile article).
Along the lines of some of the other suggestions on this forum, there are DSP chips like the TMS320VC55xx series which combine USB and DSP. This would be ideal for folks wanting to create a digital XO with multiple DAC boards attached. But the TMS320 USB is probably more difficult to program than other uC options, particularly the USB-Audio feature. The non-DSP options are probably roughly equivalent, such that you're probably better off finding a firmware volunteer first, and then select a uC based upon the available experience of the volunteer.
I don't think the board needs a DAC. I think the board should be able to accomodate a DAC if the user so desires, and can use a bus connection from the I2S out to another DAC if the user prefers that instead. In other words, maximum flexibility, with the option to have everything on one board if people so desire. I see no drawback besides possibly the size of the (unpopulated) board itself, plus added complexity in design.
I think we can expect as many "buy and forget" people to buy the board without enclosure as there are members of the group of audiophiles with less money and more time than their doctor has, and who are handy enough to start something DIY to even up the disparity.
Although your point is well taken, my point re the Arduino is that every single thing it does, every project it's ever been employed in, could be done without an Arduino. But it's easier with one, so people use it who otherwise wouldn't even start. I think those people could be convinced to buy a board if it's easy enough to complete. Once you know everything, everything's easy. When you don't, it always helps if there is a cut-and-dried path to take.
For the rest, it would be modification-friendly, so away you go. Intrepid DIYers could even make a little extra finishing boards ... eg adding a DAC ... and roll down the cost of their own unit even further. I see it as being all about economies of scale, since that's where a lot of the DIY successes and failures diverge.
Hey, I'm just saying what I think. I don't want to see it split into multiple camps all chasing the same dragon. If USB-I2S is all everyone wants, do it that way. Even though it adds a potential problem (properly terminating the I2S connection, choosing a suitable cable, etc) it still will work. But I think having the option of avoiding that has more potential. A good interface cable is good, no interface cable is better.
Last edited:
That's a great idea, and I don't see anything wrong with it other than the size, which you've already pointed out. As long as there is I2S out, making it easy to select a different DAC, then I think the main board can meet everyone's needs. There might be some additional cost to producing two variations on the board, but the costs will be minimal if the board is the same and the only real difference is leaving off the DAC and analog section. About the most difficult aspect will be predicting how many of each to assemble.
I see your points as well, but I think that the audiophile aspect throws a wrench in the comparison with Arduino. I don't think there are any seriously high-end projects based on the Arduino. I can't imagine that anyone working with the Arduino is worried about the quality of the solution - the sole criterion seems to be: if it works at all, that's good enough. Although many audiophile products are overpriced, the truth is that audiophile quality generally costs more. It's certainly possible to do something very similar to Arduino in the audiophile world, but it will take a certain amount of attention to details such that the desired quality can be achieved by those who might consider purchasing such a DIY solution.
In other words, it would certainly be much easier for someone to build a DIY USB-Audio DAC with a board like what is being described, but if they're locked into a particular DAC chip then I think that would be a bigger detriment than might be seen in the Arduino world with respect to features available there.
By the way, my hope is that setting a standard for the DAC expansion connector might create a market for DAC boards that can be plugged in without a lot of esoteric knowledge. Right now, we have SPDIF as the universal interconnect, and certain sectors of the industry are trying to make HDMI the new universal interconnect (although I don't think HDMI seems to be faring very well in the audiophile world). Admittedly, an I2S interconnect would not be very useful for connecting multiple chassis, but such a standard could make it easy to swap a DAC board inside a DIY chassis for an upgrade and just reconnect the power, I2S, and possibly control signals that work for every board in this new category. Granted, this might require new firmware to be compiled for the main board, but that can also be solved in ways that aren't completely beyond the "buy and forget" types.
Last edited:
Hello guys,
after a while, I must say that I'm close to finish my USB to I2S application based purely on XMOS reference design... with a few changes to accomodate to my PCB needs. The schematic is almost identical to that posted on XMOS site, no facy stuff here, no multichannel support, only stereo.
The board will provide one I2S output (since main reason for developing was for playback only) and one S/PDIP output.
Perhaps there could be few things to notice:
1. The board is 4 layers
2. 2 oz copper thickness for all layers OR 1oz for outer layers and 2 oz for GND planes (I'm still in debate)
3. Ultra low phase noise oscillators (22.5792 Mhz and 24.576 Mhz).
4. OsCONs are present, heavy decoupling for every IC, NP0 most of them.
5. Seven low noise voltage regulators. Every oscillator will have a dedicated voltage regulator mounted under it (keep trace lengths to minimum). The Logic ICs in clock signal's path also have a dedicated PSU.
6. Board provide two USB inputs: one is USB-B mounted on the PCB while the other could be like this
7. The board could be powered using USB 5V or from an 5V external source (still debatable)
8. 24 bit/ up to 192 khz sample rate support. It's far from "ultimate" sollution but it's a start.
Unfortunately, no I2S LVDS support and isolation. From my perspective these sollutions could be added externaly to the board. The driver is Thesycon's work so it will support all the OSes listed on their web site (including Windows Vista/7 and MAC OS) and proprietary ASIO support.
My PCB is not ready yet, and I could make few changes to the I2S/SPDIF outputs so any help in this matter would be apreciated.
Kind regards,
L
after a while, I must say that I'm close to finish my USB to I2S application based purely on XMOS reference design... with a few changes to accomodate to my PCB needs. The schematic is almost identical to that posted on XMOS site, no facy stuff here, no multichannel support, only stereo.
The board will provide one I2S output (since main reason for developing was for playback only) and one S/PDIP output.
Perhaps there could be few things to notice:
1. The board is 4 layers
2. 2 oz copper thickness for all layers OR 1oz for outer layers and 2 oz for GND planes (I'm still in debate)
3. Ultra low phase noise oscillators (22.5792 Mhz and 24.576 Mhz).
4. OsCONs are present, heavy decoupling for every IC, NP0 most of them.
5. Seven low noise voltage regulators. Every oscillator will have a dedicated voltage regulator mounted under it (keep trace lengths to minimum). The Logic ICs in clock signal's path also have a dedicated PSU.
6. Board provide two USB inputs: one is USB-B mounted on the PCB while the other could be like this
7. The board could be powered using USB 5V or from an 5V external source (still debatable)
8. 24 bit/ up to 192 khz sample rate support. It's far from "ultimate" sollution but it's a start.
Unfortunately, no I2S LVDS support and isolation. From my perspective these sollutions could be added externaly to the board. The driver is Thesycon's work so it will support all the OSes listed on their web site (including Windows Vista/7 and MAC OS) and proprietary ASIO support.
My PCB is not ready yet, and I could make few changes to the I2S/SPDIF outputs so any help in this matter would be apreciated.
Kind regards,
L
Last edited:
Lorien ... very interesting post.
That is a great idea and worth exploring.
Of course, if it's worth doing, it's worth doing right. Here we are playing with I2S to a large extent because the alternatives were done wrong for no good reason. Certainly we should avoid that if we intend to create something that has any chance of being adopted by careful users.
I share your suspicion of HDMI. It has the advantage of being relatively cheap and easy to source, with both cables and the board connectors relatively easy to obtain. Having said that, since they are nothing more than CatX cable with a shield, one wonders why they cost as much as they do, as low as it may be. Shielded CatX cables are available, by the way, with a specified 150 ohm characteristic impedance, but see below.
After price and current ease of sourcing, that's where the advantage ends, as far as I can see. It seems to be another case of choosing a convenient solution over a "proper" solution, which can only result in having to look at the problem once more in the future, when there is no good reason to have the problem in the first place.
HDMI cables are all made in China * and to a price, as far as I can tell. You cannot find a decent specification of an HDMI cable. It is a twisted-pair configuration, which suffers from a certain ambiguity when it comes to characteristic impedance ... it's said no twisted pair cable can be specified tighter than +/- 15% for characteristic impedance.
I believe they are supposed to be 100 ohms, but 85~115 ohms (in a well made example) is not a reassuring performance window for I2S in my opinion. That's not even considering the possibility that the examples available on the market may not be built to meet that range in the first place (why are longer HDMI cables so expensive ... is that because short ones pay no attention to characteristic impedance at all?).
Coax can be +/- 2% (as can BNC connectors). At this point I would be leaning towards coax and BNC 50 ohm ... because the 50 ohm connectors are not used in the consumer space and therefore the manufacturers build to a broadcast standard and publish robust specifications. They do not cost more than 75 ohm variants made by reliable manufacturers.
However a different connector might also work, assuming it could work to terminate coax.
They are easy to DIY and can be built to a known characteristic impedance. The downside is multiple coax cables would be required and they could be a bit stiff. Multiple Coax bundles and higher flex coax are used in broadcast so there will be many options to explore.
They would not necessarily need connectors if used within the same enclosure, nor do we necessarily have to use a BNC connector, as long as we agree that RCA is right out ... characteristic impedance of RCAs may as well be spec'd with the use of a dartboard in the marketing office.
* Blue Jeans Cable is said to make a HDMI cable that is partly made in China and substantially made in the US.
That is a great idea and worth exploring.
Of course, if it's worth doing, it's worth doing right. Here we are playing with I2S to a large extent because the alternatives were done wrong for no good reason. Certainly we should avoid that if we intend to create something that has any chance of being adopted by careful users.
I share your suspicion of HDMI. It has the advantage of being relatively cheap and easy to source, with both cables and the board connectors relatively easy to obtain. Having said that, since they are nothing more than CatX cable with a shield, one wonders why they cost as much as they do, as low as it may be. Shielded CatX cables are available, by the way, with a specified 150 ohm characteristic impedance, but see below.
After price and current ease of sourcing, that's where the advantage ends, as far as I can see. It seems to be another case of choosing a convenient solution over a "proper" solution, which can only result in having to look at the problem once more in the future, when there is no good reason to have the problem in the first place.
HDMI cables are all made in China * and to a price, as far as I can tell. You cannot find a decent specification of an HDMI cable. It is a twisted-pair configuration, which suffers from a certain ambiguity when it comes to characteristic impedance ... it's said no twisted pair cable can be specified tighter than +/- 15% for characteristic impedance.
I believe they are supposed to be 100 ohms, but 85~115 ohms (in a well made example) is not a reassuring performance window for I2S in my opinion. That's not even considering the possibility that the examples available on the market may not be built to meet that range in the first place (why are longer HDMI cables so expensive ... is that because short ones pay no attention to characteristic impedance at all?).
Coax can be +/- 2% (as can BNC connectors). At this point I would be leaning towards coax and BNC 50 ohm ... because the 50 ohm connectors are not used in the consumer space and therefore the manufacturers build to a broadcast standard and publish robust specifications. They do not cost more than 75 ohm variants made by reliable manufacturers.
However a different connector might also work, assuming it could work to terminate coax.
They are easy to DIY and can be built to a known characteristic impedance. The downside is multiple coax cables would be required and they could be a bit stiff. Multiple Coax bundles and higher flex coax are used in broadcast so there will be many options to explore.
They would not necessarily need connectors if used within the same enclosure, nor do we necessarily have to use a BNC connector, as long as we agree that RCA is right out ... characteristic impedance of RCAs may as well be spec'd with the use of a dartboard in the marketing office.
* Blue Jeans Cable is said to make a HDMI cable that is partly made in China and substantially made in the US.
Last edited:
Update: 75 ohm BNC appears to be higher bandwidth.
100 ohms +/- 15% characteristic impedance is the allowable tolerance in the HDMI specification. The possibility exists that there are HDMI cables that do not meet that spec.
Last edited:
I have just sent a board for prototyping what I'm hoping is a reasonable approach to this problem. I haven't written any code yet, or worked with the I2S peripheral on the chosen uC before, so we'll have to see.
The plan is based around STM32F105 - a 32-bit ARM Cortex-M3 with USB full-speed, Ethernet and 2xI2S. Firmware can be loaded via USB on a bare device, which is nice for DIY, and one of the main reasons I chose this chip - no special programming hardware or an out-of-band UART is required to build it from scratch. It's readily available at about $5, and fairly easy to use in LQFP64.
What I am hoping is possible, and seems to be from the datasheet, is building a simple device, basically just the STM32 and supporting components, with I2S in slave mode (master mode is possible as well using internal PLL, but I doubt anyone here is seriously interested in that). It should be possible to support 4 channels, either 2x2 or 4x0 at 24bit/96KHz. The specsheet doesn't say that 192KHz is possible, but it might be, given the datasheet description I think it would probably work if the required clock is provided. Full-speed USB is not enough bandwidth for 4 channels at 192KHz, but 2 might be possible if the peripheral will do it, but it's close to the limit of USB FS. For 192KHz USB HS is really required, but few uCs that are reasonable to DIYers support it.
I haven't gotten that far into planning the actual implementation, but there will be some external interface for the uC to control the clock, DAC and an external PGA, probably I2C - I2C->SPI bridges are inexpensive if necessary on the DAC board, and I2C GPIO can be used for a programmable clock (if desired).
I am hoping to implement UAC2 to support asynchronous audio properly. As far as I am aware there isn't a driver for UAC2 on Windows, but as I don't use that OS to play audio, it doesn't bother me. If I can, I'll make the USB VID/PID programmable (along with other parameters) via USB, so it may be possible to emulate a commercial UAC2 device and use their driver.
Much code is yet to be written, and the design idea verified. Does this approach sound reasonable and will it fulfill the needs of most users? The hope is that such a modular design should be able to support pretty much any DAC and clock with only minimal firmware development - possibly just configuration from the PC side. If the I2S part works, I plan to design a simple dual-timebase clock divider to generate at least 44.1/48/88.2/96 clocks and at least one DAC module to go with it, but I don't plan to force anyone's hand with design of these critical parts - it should be pretty easy to use any parts you would like, and I aim to make doing so as seamless as possible.
All code and design files will be open under a non-commercial license.
The plan is based around STM32F105 - a 32-bit ARM Cortex-M3 with USB full-speed, Ethernet and 2xI2S. Firmware can be loaded via USB on a bare device, which is nice for DIY, and one of the main reasons I chose this chip - no special programming hardware or an out-of-band UART is required to build it from scratch. It's readily available at about $5, and fairly easy to use in LQFP64.
What I am hoping is possible, and seems to be from the datasheet, is building a simple device, basically just the STM32 and supporting components, with I2S in slave mode (master mode is possible as well using internal PLL, but I doubt anyone here is seriously interested in that). It should be possible to support 4 channels, either 2x2 or 4x0 at 24bit/96KHz. The specsheet doesn't say that 192KHz is possible, but it might be, given the datasheet description I think it would probably work if the required clock is provided. Full-speed USB is not enough bandwidth for 4 channels at 192KHz, but 2 might be possible if the peripheral will do it, but it's close to the limit of USB FS. For 192KHz USB HS is really required, but few uCs that are reasonable to DIYers support it.
I haven't gotten that far into planning the actual implementation, but there will be some external interface for the uC to control the clock, DAC and an external PGA, probably I2C - I2C->SPI bridges are inexpensive if necessary on the DAC board, and I2C GPIO can be used for a programmable clock (if desired).
I am hoping to implement UAC2 to support asynchronous audio properly. As far as I am aware there isn't a driver for UAC2 on Windows, but as I don't use that OS to play audio, it doesn't bother me. If I can, I'll make the USB VID/PID programmable (along with other parameters) via USB, so it may be possible to emulate a commercial UAC2 device and use their driver.
Much code is yet to be written, and the design idea verified. Does this approach sound reasonable and will it fulfill the needs of most users? The hope is that such a modular design should be able to support pretty much any DAC and clock with only minimal firmware development - possibly just configuration from the PC side. If the I2S part works, I plan to design a simple dual-timebase clock divider to generate at least 44.1/48/88.2/96 clocks and at least one DAC module to go with it, but I don't plan to force anyone's hand with design of these critical parts - it should be pretty easy to use any parts you would like, and I aim to make doing so as seamless as possible.
All code and design files will be open under a non-commercial license.
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.