• WANTED: Happy members who like to discuss audio and other topics related to our interest. Desire to learn and share knowledge of science required as is 20 years of participation in forums (not all true). There are daily reviews of audio hardware and expert members to help answer your questions. Click here to have your audio equipment measured for free!

Sabaj A20d Review (Balanced DAC)

garbz

Member
Joined
Sep 17, 2021
Messages
99
Likes
112
OK, yes I guess I needed an other coffee and was completely off with the frequency. Lot of things in what you say make sense, but not enough to say "cant work". Cables can transport much higher speed, and well, as I said, Developpers do this all the time, connecting 2 boards together with I2S. As for Jitter, sorry I didn't get your point. Why exactly it's intrinsyncly worst? You don't have to define the incoming I2S clock as the master clock as for autodetect nothing that can't be done. I agree this is Frankensteinish as of now but I don't see any of this as a fatality.
One cable is not another cable. The ability to transfer at speed is highly dependent on the sensitivity and characteristics of the electrical signals, how they are transferred, the characteristics of the cable, the transmitter, and the receiver. High speed TTL signals are designed to be transferred only a few cm. It works in a pinch yeah. Works great testing too. But it is not in any way "good", and by that I mean anything from causing poor performance to potentially interfering with other components in your design. Also what works on the bench is not necessary what works in the living room when someone takes your final product and does whatever it is they do with it using whatever poor crap they found laying in the bottom of their drawer. For transmission over any distance you universally never use TTL signals. It does not work over any appreciable distance, and I can't stress this enough: it was tried and failed which is precisely why I2S is converted to LVDS before being sent over HDMI in practice.
It's no different to the serial connections from the 80s. USART is TTL, it was designed to transmit over very short distances. As soon as you wanted to connect a printer you would use RS-232 instead with its 15V instead of 5V and short circuit protection.

Speaking of protection, you're completely missing the human aspect here too. I2S is designed to be permanently connected and terminated between chips. Datasheets give you instructions of what to do with unconnected inputs and outputs in your design. They are also not in any way designed to be floating and disconnected, and simply the act of walking across the room and touching the connector can potentially fry your DAC chips. I2S affords no protection against short circuit, over voltage, incorrect connection, static electricity, etc, etc. Quite different from an LVDS transmitter or receiver.

To your last point I now don't get your point. If you're not defining the incoming clock as the master clock when using I2S then I really ask what you're hoping to achieve. I2S's only benefit as a connection is its clocking. If you're not going to use it then why go through this pointless exercise? Why Frankenstein together something in a way it was never designed to be used when you're not going to use its main marketable benefit it affords over the common and well defined S/PDIF or AES3 standard?

Also I say "marketable" because the benefit certainly isn't measurable.

Standardisation ACTUALLY adds cost, you know that a licence to have a USB port is about 4K a year?
No that's not the cost of standardisation. That's the cost of certification and licensing. You can create a USB device for free, you're just not allowed to market it as USB or display the USB logo on it. And while you point to USB as a costly standard, I could point you to hundreds of others which are completely free, e.g. every serial standard used RS-232, RS-422, RS-485, ... errr wait, how about I2S (it is after all a standard when used correctly).

If the port works, the port works. If there is a formal standard or just a casual agreement, what does it matter? I haven't seen posts saying, "I2S doesn't work!" I have been seeing posts complaining about some violated aesthetic engineers hold dear.
Not having seen something doesn't mean it doesn't exist. Companies themselves are very clear that there's zero guarantee that I2S will work. They don't say this because they like to advertise their features in this way. They say this because they there's no formal standard. You're right about one thing *IF* the port works, it works. But that "IF" is precisely what standards seek to resolve.
 
Last edited:

PeteL

Major Contributor
Joined
Jun 1, 2020
Messages
1,972
Likes
1,964
One cable is not another cable. The ability to transfer at speed is highly dependent on the sensitivity and characteristics of the electrical signals, how they are transferred, the characteristics of the cable, the transmitter, and the receiver. High speed TTL signals are designed to be transferred only a few cm. It works in a pinch yeah. Works great testing too. But it is not in any way "good", and by that I mean anything from causing poor performance to potentially interfering with other components in your design. Also what works on the bench is not necessary what works in the living room when someone takes your final product and does whatever it is they do with it using whatever poor crap they found laying in the bottom of their drawer. For transmission over any distance you universally never use TTL signals. It does not work over any appreciable distance, and I can't stress this enough: it was tried and failed which is precisely why I2S is converted to LVDS before being sent over HDMI in practice.
It's no different to the serial connections from the 80s. USART is TTL, it was designed to transmit over very short distances. As soon as you wanted to connect a printer you would use RS-232 instead with its 15V instead of 5V and short circuit protection.

Speaking of protection, you're completely missing the human aspect here too. I2S is designed to be permanently connected and terminated between chips. Datasheets give you instructions of what to do with unconnected inputs and outputs in your design. They are also not in any way designed to be floating and disconnected, and simply the act of walking across the room and touching the connector can potentially fry your DAC chips. I2S affords no protection against short circuit, over voltage, incorrect connection, static electricity, etc, etc. Quite different from an LVDS transmitter or receiver.

To your last point I now don't get your point. If you're not defining the incoming clock as the master clock when using I2S then I really ask what you're hoping to achieve. I2S's only benefit as a connection is its clocking. If you're not going to use it then why go through this pointless exercise? Why Frankenstein together something in a way it was never designed to be used when you're not going to use its main marketable benefit it affords over the common and well defined S/PDIF or AES3 standard?

Also I say "marketable" because the benefit certainly isn't measurable.


No that's not the cost of standardisation. That's the cost of certification and licensing. You can create a USB device for free, you're just not allowed to market it as USB or display the USB logo on it. And while you point to USB as a costly standard, I could point you to hundreds of others which are completely free, e.g. every serial standard used RS-232, RS-422, RS-485, ... errr wait, how about I2S (it is after all a standard when used correctly).


Not having seen something doesn't mean it doesn't exist. Companies themselves are very clear that there's zero guarantee that I2S will work. They don't say this because they like to advertise their features in this way. They say this because they there's no formal standard. You're right about one thing *IF* the port works, it works. But that "IF" is precisely what standards seek to resolve.

How do you get to "A few centimeters" ? You keep stating generalities, I've done it with generic ribbon cables, even with aligator cables, It works. a HDMI cable can transport video, they themselves do have standards and its more data than an audio signal. In any systems you have to study what is master and what is slaved, and this has all the necessary signal to do so, You don't know or I Don't know what the designer did, you don't know what initialization routine is performed, you don't know how clocking is implemented. SPDIF signals have clocking information too by the way, but the designer decides if there is reclocking, if there is clock recovery, all that is not fixed, but the full I2S bus is more flexible, not necessary better, but more flexible. It's just digital audio. All your argument is based on "designed to be used only a few cm" Where do you get that from? How many cm is OK? Did you look at the Eye Diagram and calculate the error rate, and return loss over a couple feet to these conclusions? I am assuming that the designer of this DAC did. I believe in good faith unless proven otherwise and I don't find in your argument that you proved it would fail. Did you even try it? By the way control signals work well beyond a few cm too....;

Edit: You got me interested really, As I said I am too lazy to do the full analysis, this would require to much reading, remembering and studying, but I was interested in general ball park. Using this simple rule of thumb formula:


At 24MHz, 6.25m would be the distance above with we would have to use a transmission line. those are gross numbers and I'll admit that when I was remembering to do this properly, My numbers where lower than that... But I remember doing this analysis in the past for a SPDIF signal and It was coming up to about 2 feets where you would need to worry about using a 75 ohm proper characteristic impedance as a coax transmission line. below that it just didn't matter. So yes I take this 6m number with some doubts, but seem extreme to me that the real number would be just a few cm. Really interested how you'd come to that.
 
Last edited:

Helicopter

Major Contributor
Forum Donor
Joined
Aug 13, 2020
Messages
2,648
Likes
3,761
Location
Michigan
Thanks Amir.

This looks to ba a great DAC, with a signature look. Not my favorite, but acceptable and different. I like that they have an artistic edge with this stuff to differentiate Sabaj, Loxjie, and SMSL.

Too bad about the HDMI thingy. I know HDMI licenses are a crazy ripoff. But this still gets me thinking, what would it take to do a DAC that takes HDMI audio and converts it to 5.1 or 5.2 channel line level with PEQ for sub crossovers, room correction and speaker correction? I could plug a Sony UBP and play 5.1 channel SACDs on it in HiFi... and I could use it as a source for vintage quadraphonic gear in the similar configuration. I digress.
 
Joined
Oct 9, 2021
Messages
30
Likes
17
Location
Fajãzinha, Flores, PT
I would like to add four thoughts as my first post:
External build quality seems not fully on par with Gustard A18 or X16 DACs from that price range, in particular the display with it's limited informative value.
Easily avoidable A20a PSU board issue made a very negative impression - which should not be forgiven too early!
Compared to the A10d DAC or the A20a + A20h amps this one here appears as a little bit pricey.
MQA toll included in the price once more. It's like telling a vegan to just leave an obligatorily paid and served sausage untouched if you don't want it.
 

garbz

Member
Joined
Sep 17, 2021
Messages
99
Likes
112
How do you get to "A few centimeters" ? You keep stating generalities, I've done it with generic ribbon cables, even with aligator cables, It works.
You can transmit audio by putting two cups together and putting a piece of string in them. If you want "it works" then go buy a $2 soundbar from Alibaba. There's a world of difference between testing something on a bench to see if it works and actually producing a quality working result.
You know this. At least I think you know this because you're talking about transmission lines but somehow forgetting that the application of a transmission line is a very carefully engineered design catered to the signal in question. The "few centimeters" I talk about is precisely because I2S was not meant for being sent down a transmission line, it was meant to be sent between two chips. If it were meant for a transmission line it wouldn't be 5V TTL logic because we engineers flat out don't do something that stupid, and neither do people pushing it over HDMI (as you can see by the fact that I2S isn't sent over HDMI but rather converted to something else first).

You don't know or I Don't know what the designer did, you don't know what initialization routine is performed, you don't know how clocking is implemented
Exactly the problem. A problem that doesn't exist when there's a standard for interconnection.

SPDIF signals have clocking information too by the way, but the designer decides if there is reclocking, if there is clock recovery, all that is not fixed
Indeed which is why I mentioned it. I invite you to re-read my comment because I think you didn't understand it the first time around.

All your argument is based on "designed to be used only a few cm" Where do you get that from? How many cm is OK? Did you look at the Eye Diagram and calculate the error rate, and return loss over a couple feet to these conclusions?
a) Basic engineering guidelines for TTL communication between ICs at that rate.
b) How many cm depends on your PCB design and layout.
c) Yes, I always look at eye diagrams after laying out high speed signals.
I assume if you ever looked at an eye diagram of an I2S signal sent over a few cables on your test bench we wouldn't be having this discussion, you'd simply be nodding in agreement.

At 24MHz, 6.25m would be the distance above with we would have to use a transmission line.
No. At 6.25m a transmission line becomes essential to get a discernable signal at the other end. If you're designing marginal crap for a $2 soundbar then by all means throw shit together and ship it. Just don't expect anyone to praise your efforts after it gets put on a test bench. You seem to think the only thing which matters is the signal arriving as well, what about the rest of your board? At 24MHz if you just slap things together you may well be designing a radio source as well, you may be coupling noise into the ground. No one is interesting in if you or I can get something to work. They are interested in buying a high performance piece of precision gear which requires actual engineering even if your traces aren't 6.25m long. Even at only a few cm it matters how far apart your traces are, how they are routed, how vias are used, the distance from the groundplane. There's far more to this than setting up an RF transmission line.


Let me go back to my main point: What problem are you solving? Just throwing the word I2S in the mix doesn't solve anything if your implementation is a lot of effort which may or may not work, and when it does work performs worse than simply using S/PDIF in the first place.
 

PeteL

Major Contributor
Joined
Jun 1, 2020
Messages
1,972
Likes
1,964
You can transmit audio by putting two cups together and putting a piece of string in them. If you want "it works" then go buy a $2 soundbar from Alibaba. There's a world of difference between testing something on a bench to see if it works and actually producing a quality working result.
You know this. At least I think you know this because you're talking about transmission lines but somehow forgetting that the application of a transmission line is a very carefully engineered design catered to the signal in question. The "few centimeters" I talk about is precisely because I2S was not meant for being sent down a transmission line, it was meant to be sent between two chips. If it were meant for a transmission line it wouldn't be 5V TTL logic because we engineers flat out don't do something that stupid, and neither do people pushing it over HDMI (as you can see by the fact that I2S isn't sent over HDMI but rather converted to something else first).


Exactly the problem. A problem that doesn't exist when there's a standard for interconnection.


Indeed which is why I mentioned it. I invite you to re-read my comment because I think you didn't understand it the first time around.


a) Basic engineering guidelines for TTL communication between ICs at that rate.
b) How many cm depends on your PCB design and layout.
c) Yes, I always look at eye diagrams after laying out high speed signals.
I assume if you ever looked at an eye diagram of an I2S signal sent over a few cables on your test bench we wouldn't be having this discussion, you'd simply be nodding in agreement.


No. At 6.25m a transmission line becomes essential to get a discernable signal at the other end. If you're designing marginal crap for a $2 soundbar then by all means throw shit together and ship it. Just don't expect anyone to praise your efforts after it gets put on a test bench. You seem to think the only thing which matters is the signal arriving as well, what about the rest of your board? At 24MHz if you just slap things together you may well be designing a radio source as well, you may be coupling noise into the ground. No one is interesting in if you or I can get something to work. They are interested in buying a high performance piece of precision gear which requires actual engineering even if your traces aren't 6.25m long. Even at only a few cm it matters how far apart your traces are, how they are routed, how vias are used, the distance from the groundplane. There's far more to this than setting up an RF transmission line.


Let me go back to my main point: What problem are you solving? Just throwing the word I2S in the mix doesn't solve anything if your implementation is a lot of effort which may or may not work, and when it does work performs worse than simply using S/PDIF in the first place.
Again Garbz, all your argument are valid If you are trying to demonstrate that "It may not work as intended if they are no guidelines and standards" I agree with this, but we are having a discussion that is going nowhere because my argument is "It may work and it may be useful in the future" PCB design and layout always matter, I never questioned that. Amir tested it (I2S trough a HDMI cable) here, no indications that it did not work. Yes there was a sample delay on that exemple but this is obviously implementation, not a problem with I2S or signal degradation. Do you doubt Amir's testing? Again, read this again. 24 MHz is NOT hi speed. I repeat 24 MHz is not hi speed. It is a easily transportable signal If implemented properly. I already admitted that this 6 meter was not a valid number, but an indicator of the order. You said it yourself. It can be converted to LVDS. The problem I have with your argument is that they are blanket statements. The "can't work". I have no problem with the "may not work well". The I2S Interface on this has not been tested, so we don't know. SMSL does a Streamer with I2S out so don't you think they would have not tested it? Iron out the culprint? Do you KNOW for a FACT that in this setting the signal is degraded in a measurable way? And by the way, all standards start with an engineer experimenting and implementing something his own way.
 
Last edited:

PeteL

Major Contributor
Joined
Jun 1, 2020
Messages
1,972
Likes
1,964
You can create a USB device for free, you're just not allowed to market it as USB or display the USB logo on it.
Technically, no. No USB device will be recognised by any OS without a Vendor ID. Same with Bluetooth.
 
OP
amirm

amirm

Founder/Admin
Staff Member
CFO (Chief Fun Officer)
Joined
Feb 13, 2016
Messages
37,366
Likes
156,036
Location
Seattle Area
Amir tested it (I2S trough a HDMI cable) here, no indications that it did not work.
Actually it didn't at first. I was getting phase errors and only later realized there are so many variations of this interface and flipped a dip switch did it work: https://www.audiosciencereview.com/forum/index.php?threads/study-is-i²s-interface-better-for-dacs-than-s-pdif-or-usb.7105/

index.php


As seen by Gustard's own devices not showing the same problem:

index.php


Without instrumentation I don't know how anyone would have discovered this. And then went on to talk about staging changing due to that phase shift.

This was a hack that has become more widespread. It has no reason to exist and should be dismissed as broken and of no value.
 

sarumbear

Major Contributor
Forum Donor
Joined
Aug 15, 2020
Messages
3,256
Likes
2,929
Location
Southampton, UK
Technically, no. No USB device will be recognised by any OS without a Vendor ID. Same with Bluetooth.
Does that mean that a computing device, which has no connection to the Internet or other means of upgrading will not recognise a device made by a new vendor that didn’t exist when that device was manufactured?
 

PeteL

Major Contributor
Joined
Jun 1, 2020
Messages
1,972
Likes
1,964
Actually it didn't at first. I was getting phase errors and only later realized there are so many variations of this interface and flipped a dip switch did it work: https://www.audiosciencereview.com/forum/index.php?threads/study-is-i²s-interface-better-for-dacs-than-s-pdif-or-usb.7105/

index.php


As seen by Gustard's own devices not showing the same problem:

index.php


Without instrumentation I don't know how anyone would have discovered this. And then went on to talk about staging changing due to that phase shift.

This was a hack that has become more widespread. It has no reason to exist and should be dismissed as broken and of no value.
Again Amir, You are talking implementation, and you are trying to dismiss an argument I am not even making. The question is. Do those measurments prove that an I2S signal cannot work without measurable degradation past a few cm?? We already know there are no standards, you don't have to convince me of that. Bottom line, there was dip switches to make it work. I don't hink you need instrumentation, but you do need proper documentation. If the current manufacturers don't document properly, that is certainly a problem, but it's a different problem than a "broken design". For the "has no value" point. Me my point is that it's much cheaper to implement than USB, and it does things that spdif cannot do. SPDIF have been around since the 80s, it's starting to show it's limitations. just a new option that may or may not be useful in the future. Let,s settle for it has no value for you. It has value for me.
 
Last edited:

PeteL

Major Contributor
Joined
Jun 1, 2020
Messages
1,972
Likes
1,964
Does that mean that a computing device, which has no connection to the Internet or other means of upgrading will not recognise a device made by a new vendor that didn’t exist when that device was manufactured?
Not fully sure, but that means what it means, typically when you developp with USB, your Dev environment has a Vendor ID. You can use it in your prototype, it works. sure there might be ways to cheat, how an OS knows if you are the correct vendor with the ID, maybe it don't. but it doesn't mean you are allowed to do it. It's very likely that a computing device will accept not yet allocated IDs. I'm not discussing hacks or ways to cheat, but in all cases you'll have to enter a valid ID, if you don't have one, you have one that belong to someone else. The OS just need one.
 
Last edited:
Joined
Oct 9, 2021
Messages
30
Likes
17
Location
Fajãzinha, Flores, PT
Not fully sure, but that means what it means, typically when you developp with USB, your Dev environment as a Vendor ID. You can use it in your prototype, it works. sure there might be ways to cheat, how an OS knows if you are the correct vendor with the ID, maybe it don't. but it doesn't mean you are allowed to do it. I'm not discussing hacks or ways to cheat, but in all cases you'll have to enter a valid ID, if you don't have one, you have one that belong to someone else. The OS just need one.
E/g, I received this message here yesterday by ibasso as the DC04 dongle DAC refused to work with USB 3.0/USB 3.1 ports of my AMD Ryzen based system. Some people may consider it as defective hardware, but it's just a matter of invalid identification.
"Hello,
Thank you for contacting us.
We have reported the AMD CPU support issue to the USB receiver provider. They will provide a new firmware in the next two weeks.
Sincerely
iBasso Audio"
 

garbz

Member
Joined
Sep 17, 2021
Messages
99
Likes
112
Amir tested it (I2S trough a HDMI cable) here, no indications that it did not work.
Peter, please understand that your original comment and the entire point I have been making is *NOT* in any way shape or form what Amir tested. This entire discussion was predicated on you disagreeing with a part of my comment, that I2S was designed for interchip communication across a few centimeters.
Yet it seems your entire counter-argument to this is: a) it works on a breadboard, and b) Amir tested it. Yes it does work on a breadboard. Not well. No Amir did not test this. Amir tested LVDS over HDMI carrying I2S. You can go back to my original comment on the first page if you want to understand the difference as well as the implication of making up standards.

Fundamentally you need to understand that I2S out of the back of the DAC is *NOT* I2S, it's a made up bolted together Frankenstein system which some vendor wrote I2S on. When you wrap your head around this then all the posts here will make sense, including the ones talking about I2S only being suitable for communication over a few cm.

24 MHz is NOT hi speed. I repeat 24 MHz is not hi speed.
You say this as if this statement has any meaning. You're so focused on the transmission line concept that you're ignoring that the frequency of transmission is not the limiting factor here. In the second year of uni you want to know what one of our PCB layout exams was on? Re-routing a trace such that a single transition from one to zero wouldn't cause a spike in a neighbouring signal trace. No 24MHz, just one transition change. No one I have ever met professionally brushes off 24MHz as "not hi speed", and no one I have ever met thinks that any digital signal, no matter how small can be brushed off in a mixed signal environment, let alone a precision one. In a mixed signal environment you need to put the same care and thought into all your traces, whether they be some mythical threshold you would consider high speed, or a simple pushbutton to the front of the chassis because it's not the frequency of the signal which you need to worry about, it's the speed of its transition.

Technically, no. No USB device will be recognised by any OS without a Vendor ID.
Who said anything about recognised? You're confusing implementing a standard and licensing it. USB defines generic Vendor IDs for many of the generic subclass devices. What you need is a unique Product ID and you get both when licensing something. But if you don't license something there's no license agreement to break. And the world is literally littered with millions of cheap crap products using generic VIDs with identical PIDs which are unlicensed and yet work just fine and are recognised by all OSes as a result, and that's assuming your product doesn't use a commercial sublicensed USB transmitter which comes with a VID/PID baked in. e.g. My outdoor weather station which identifies itself with the VID from Atmel. Atmel sure as heck didn't make it.
 

PeteL

Major Contributor
Joined
Jun 1, 2020
Messages
1,972
Likes
1,964
Peter, please understand that your original comment and the entire point I have been making is *NOT* in any way shape or form what Amir tested.
OK, I think this discussion don't need to be pursued. I wanted to discuss the option, like in the case of this DAC, of an I2S interface, transported trough a HDMI cable, IE, what Amir tested. Instead you want to enumerate the basics of PCB design, yep different discussion. I am talking about what we have in front of us.

"But if you don't license something there's no license agreement to break"

I have never talked about anything else that licensing, but read again what you wrote... USB Standards and IP are not mine, I need a licence to use it in my design, if not, the design is not mine, quite simple. Sure you can develop all you want, for your own use, nobody will knock at your door with a bill. You can't sell it. It's not about the USB Logo and marketing it as a USB device.
 
Last edited:

garbz

Member
Joined
Sep 17, 2021
Messages
99
Likes
112
Instead you want to enumerate the basics of PCB design, yep different discussion
No I wanted to discuss the importance of standards which was my point to begin with. We have far better ways of transmitting audio than making things up based on an interface designed only for basic on PCB communication. I repeat the same question to you I've asked three times already: What problem are you trying to solve? Justify why you would throw away a working standard interface in the audio world in favour of your frankensignals.

I have never talked about anything else that licensing
No. I introduced that topic because you said standards create cost and cited USB. That is false. 100% of the cost of USB is licensing. The standard just is. It exists. You can do with it what you want. And in the process you skipped over the literally countless standards in our world which do not have any licensing associated with them. What is the cost of implementing IEC 60958 and to whom do I need to pay a fee?
 

PeteL

Major Contributor
Joined
Jun 1, 2020
Messages
1,972
Likes
1,964
I repeat the same question to you I've asked three times already: What problem are you trying to solve? Justify why you would throw away a working standard interface in the audio world in favour of your frankensignals.
I answered that already. It is cheaper than USB and it offers more flexibility than SPDIF. I didn't say anything about throwing away a working standard. The XMOS chip on most USB design is typically the 3rd cost driver of any DAC, right after the chassis and bare PCB. But it's OK, this one is not going away anytime soon, It's at the other end the problem, designing a USB transmitter on anything else than a computer or smartphone, a network streamer for example, is very complicated and very expensive. But I am repeating myself, you just don't like my answer.
 
Last edited:

garbz

Member
Joined
Sep 17, 2021
Messages
99
Likes
112
It is cheaper than USB and it offers more flexibility than SPDIF.
An off the shelf USB audio interface no more expensive than an LVDS transmitter (and no you don't need to pay a license fee), and nothing quite says flexibility like "I do the same thing but may not work".

The XMOS chip on most USB design is typically the 3rd cost driver of any DAC, right after the chassis and bare PCB.
If there was ever any doubt as to whether or not you knew what the cost of a BOM in a DAC was you've put it to rest now. Hint: USB interfaces run at about 1/3rd of the cost of cheap DAC chips, and even less than an S/PDIF receiver, let alone high end ones, and the PCB in any kind of volume is often the cheapest component in a system. Heck last one I built I had a single PCB made for $4 Imagine if I ordered 1000.

you just don't like my answer
For good reason.

Anyway I think this conversation has gone well beyond its scope so I'll leave it there. Suffice to say there's a reason S/PDIF and USB are ubiquitous and I2S is relegated to the inside of a DAC's chassis.
 

PeteL

Major Contributor
Joined
Jun 1, 2020
Messages
1,972
Likes
1,964
An off the shelf USB audio interface no more expensive than an LVDS transmitter (and no you don't need to pay a license fee), and nothing quite says flexibility like "I do the same thing but may not work".


If there was ever any doubt as to whether or not you knew what the cost of a BOM in a DAC was you've put it to rest now. Hint: USB interfaces run at about 1/3rd of the cost of cheap DAC chips, and even less than an S/PDIF receiver, let alone high end ones, and the PCB in any kind of volume is often the cheapest component in a system. Heck last one I built I had a single PCB made for $4 Imagine if I ordered 1000.


For good reason.

Anyway I think this conversation has gone well beyond its scope so I'll leave it there. Suffice to say there's a reason S/PDIF and USB are ubiquitous and I2S is relegated to the inside of a DAC's chassis.
That's very condescending. Yes I do know the cost of a DAC BOM. I designed one, I designed other commercial products. I look at your statement, and sure, as of now DAC chips shows ridiculous pricing at like 75$ for ES9038, but I think you know the state of semi conductor market. Do you thkink it's real? the cheapest XCORE chip has never went under 12$, 2 years ago something like AK4493 was about 8$ Your GoogleFU don't tell me you've evaluated a DAC BOM cost sorry.

I agree we should put that to rest. It all started with a simple question from me that was (rephrased, because you still don't get it) How the fact that I2S as first thought of as an interchip bus automatically disqualify it to be transported through a cable. You went just about everywhere but nowhere near a technical answer to this question. You kept trying to debate other stuff, but the problem is, that's the only thing you said I disagreed with. Putting words in my mouth just to find something to argue about... I am starting to honestly doubt your good faith you have no interest in debating my question, but just want to argue.

USB is, and always has been something to be driven trough an operating system, that needs (native or not) drivers. Not everything is a computer, if you can't see that, that there are times where USB is not the most applicable solution. I don't know what more to say.
 
Last edited:

yavormoskov

Member
Joined
Apr 9, 2019
Messages
74
Likes
71
Location
Atlanta, USA
I have a question. Can I output the full 5.14 volts from Sabaj A20d if I use XLR to RCA cables to Topping A50s amplifier?
 
Top Bottom