Proper digital audio interface

[de_zeurkous]

For some personal projects -- which, although probably /very/ limited-interest, I may post about here in the future --, I've investigated some of the options to use as a pure digital audio interface. However, it seems like every 'standard' interface has severe drawbacks:

Raw PCM -> Too wide to be practical
S/PDIF -> #include <stdrant.h>
I^2S -> Too specialized
AES/ABU -> Still too narrow-minded for my tastes
USB -> What's that?
SCSI -> Just a little too hard to handle using simpler MCUs.

In response to this, I've been working on a new standard, open interface that works over every reliable, full-duplex (or half-duplex with flow control at a lower layer) transmission medium, ditches with explicit sync mechanisms, and includes 'extensive' (well, parity and CRC16 for now) error correction mechanisms. Since it also includes both a protocol versioning mechanism and has space for custom extensions, it should last for a while.

Since I finished the design while browsing this forum, you may enjoy(?) the questionable honor of being the first to inspect the design. I suggest you first read the 'General Overview' section.

As the filename indicates, it was originally intended to run specifically over an RS-485 serial interface; that intention has, fortunately, survived the design process :^)

Note that this is a draft, and I have yet to work it out into a nicely formatted manual page. In the mean time, any and all comments are much appreciated :)

Bugs:

1) More extensive error correction capabilities?
2) Parity may require bitwise addressing;
3) Support for more audio formats?
4) Fixed connection order (see 'General Overview'). I do not expect to fix this for plain serial interfaces.

[ezkcdude]

So, how would you actually implement this?

[de_zeurkous]

Using an MCU and some wits?

[gmarsh]

Problem #1: Practical implementation.

Assuming 192KHz/24 bit stereo audio, no protocol overhead and UART framing (N,8,1 - no pauses between bits), your required bit rate is 192000*3*2*10 = 11.520000 Mbps.

MCU, eh? Find me a microcontroller with a UART that can run that fast and a core that run fast enough to parse bytes at 1.52Mbyte/sec. Plus a codec/I2S interface so that it can stream audio in/out.

Oh, and it has to be a "diyable" microcontroller - an ARM926 in a BGA package isn't something your average DIYer will want to use. So 3.3V or 5V supply, leaded packaging, free or inexpensive development tools. Happy hunting.

Problem #2: Where's the clock?

This is a synchronous audio interface, right? which end drives the clock? how do you do 0ppm clock synchronization between receiving and transmitting ends? "I'm 44.1" "I'm 44.1 too!" isn't 0ppm.

I'll post more problems when I have more time.

[de_zeurkous]

Originally posted by gmarsh
Problem #1: Practical implementation.

I thought it might be :)

Assuming 192KHz/24 bit stereo audio, no protocol overhead and UART framing (N,8,1 - no pauses between bits), your required bit rate is 192000*3*2*10 = 11.520000 Mbps.

RS485 can do almost three times that speed at 10m. SPI (the SCSI Parallel Interface, not the Serial Pherephial Interface Bus) clocks RS485 even higher than that. Besides, it'll work over any full-duplex, principally reliable serial interface -- SCSI (1394!) and TCP both fit that profile, as do loads of other protocols.

MCU, eh? Find me a microcontroller with a UART that can run that fast and a core that run fast enough to parse bytes at 1.52Mbyte/sec. Plus a codec/I2S interface so that it can stream audio in/out.

Perhaps I should have said 'embedded processor'. To me personally, there is no reasonably fundamental difference.

Oh, and it has to be a "diyable" microcontroller - an ARM926 in a BGA package isn't something your average DIYer will want to use.

Then get a CPLD and synth something yourself.

So 3.3V or 5V supply, leaded packaging, free or inexpensive development tools. Happy hunting.

Pretty easy to do. No devel tools? Write your own. It's not that hard. Besides, it's just a bit stream, it's pretty easy to prototype on a development system.

Problem #2: Where's the clock?

This is a synchronous audio interface, right? which end drives the clock? how do you do 0ppm clock synchronization between receiving and transmitting ends? "I'm 44.1" "I'm 44.1 too!" isn't 0ppm.

Use buffering and throttle the rate samples get ouput. Buffer full? Reply with a 'command resend'. Using a properly designed implementation, the latter shouldn't happen that much, if at all.

I'll post more problems when I have more time. ;)

Looking forward to it :^) I want to make sure it's bulletproof...

Hm, the original intention was to have one interface per channel, but I guess for general use it should support multiple channels, if only to reduce material costs. I'll update the spec to incorporate that.

[de_zeurkous]

Done. I also added a padding facility to further cope with non-bit adressable interfaces.

Second draft

[rfbrw]

Way too much spare time.

[whatsup]

Exactly what problems does your Proper Digital Audio Interface solve. Aren’t there enough competing interfaces already? In your list of inferior interfaces you omitted Firewire and TCP/IP, among others. Do you expect industry to adopt your interface? Not likely because there are no provisions for data security or DRM. Do you expect other hobbyists to adopt it? Not likely because of its complexity, cost, and difficulty of implementation. While you and I might be able to write a complete development environment for the processor of our choice, very few others here share that ability. Besides, if I were willing to invest that kind of effort to a project I would design my own interface protocol, tailored to meet my needs and not use your over-generalized kluge.

You don’t seem to know the basics of digital data transmission protocols. For example, you specify

Messages containing CRC sums are sent prior to the message they apply to.

That’s brilliant. What do you do if the CRC doesn’t match? Resend the data message, the CRC message, or both? Either message could be in error. Are you going to send a CRC message prior to every command message because they need to be error checked as well? And if the receiver is supposed to ACK/NAK every message, then every CRC message must be ACK/NAKed and every ACK/NAK message must be preceded by its own CRC message. If you follow this to its logical conclusion, your data stream will be nothing but CRC messages. Maybe that’s why most successful data transmission protocols embed the CRC in the packet to which it applies.

And the idea that the sender and receiver can negotiate what kind of data integrity methods they should use over a connection with no data integrity is absurd. A single bit error in the negotiation could lead to an inoperable connection. One expects even parity and the other expects odd. In such a situation, neither party will accept any message from the other including Reset Device. Data integrity is not something that can be negotiated: It must be an integral part of the protocol.

[philpoole]

Problem #1: Practical implementation.

Assuming 192KHz/24 bit stereo audio, no protocol overhead and UART framing (N,8,1 - no pauses between bits), your required bit rate is 192000*3*2*10 = 11.520000 Mbps.

MCU, eh? Find me a microcontroller with a UART that can run that fast and a core that run fast enough to parse bytes at 1.52Mbyte/sec. Plus a codec/I2S interface so that it can stream audio in/out.

Piece of p**s! (LOL!)
It wasn't DIY, it was a living, but I used to write 8 bit microcontroller code that would parse 60Mbps DVB transport streams for digital TV. For my sins.
But its do-able.
Why do you need a UART as such? You could make life easier with a shift register and an IO port, or implement the shift register in software (if you have enough clock cycles).

[de_zeurkous]

Originally posted by rfbrw
Way too much spare time.

You'd be amazed how fast 'way too much spare time' passes with several Metroid games at your disposal.

Originally posted by whatsup
Exactly what problems does your Proper Digital Audio Interface solve. Aren’t there enough competing interfaces already? In your list of inferior interfaces you omitted Firewire and TCP/IP, among others.

This is a mid-level protocol -- it doesn't deal with the 'physical' (both SCSI and TCP are pretty high level, but meh) interface nor the audio stream itself. It only transports the stream and some metadata. I just happen to like RS-485, that's why I'm pushing the latter...

Do you expect industry to adopt your interface?

If I would, I would not have posted it here without any copyright notice. In fact, I would patent it and demand $0.25 per hardware vendor-supplied implementation, like IEEE1394.

I do not expect for 'the industry' -- I assume you mean the commercial establishment -- to adopt anything I design or write. I'm independent, my works are there for the public to 'enjoy', and therefore I'm at a liberty to make them the best I can.

Not likely because there are no provisions for data security or DRM.

Meh, they could just register their extensions with me and I'd update the Set Extended command set in the next version...

Do you expect other hobbyists to adopt it? Not likely because of its complexity, cost, and difficulty of implementation.

It may not be likely, but it's there for them if they ever need it.

While you and I might be able to write a complete development environment for the processor of our choice, very few others here share that ability.

Since I've not even been lurking here for very long, I can't speak for that. However, you're probably right :^)

Besides, if I were willing to invest that kind of effort to a project I would design my own interface protocol, tailored to meet my needs and not use your over-generalized kluge.

I personally prefer over-generalization to under-generalization. If you'd really want to do this right, use SCSI (is there an Audio Command Set yet? it's been a while since I inspected the specs), preferably using a 1394 PHY. In terms of DIY effort, that's probably worse than my protocol, but in the long term it would be the Right Thing to do.

You don’t seem to know the basics of digital data transmission protocols.

If I were a wikifiddler still, I would pedantly demand for reliable, third-party sources on that one.

[quote]For example, you specify {quote omitted for some reason -- zeur} That’s brilliant. What do you do if the CRC doesn’t match? Resend the data message, the CRC message, or both?[/qutoe]

Both. Forgot to note that, it'll be in the third draft.

Either message could be in error. Are you going to send a CRC message prior to every command message because they need to be error checked as well?

Of course it will. This is meant to be a principally reliable protocol. I'm sure you wouldn't appreciate the freq being set to 8kHz instead of 44.1 due to a few silly bit fallovers.

And if the receiver is supposed to ACK/NAK every message, then every CRC message must be ACK/NAKed and every ACK/NAK message must be preceded by its own CRC message.

CRC messages should not be subject to the ACK/NAK mechanism. Again, should have specified that; will be fixed.

If you follow this to its logical conclusion, your data stream will be nothing but CRC messages. Maybe that’s why most successful data transmission protocols embed the CRC in the packet to which it applies.

Just see it this way: the packet doubles in size :)

And the idea that the sender and receiver can negotiate what kind of data integrity methods they should use over a connection with no data integrity is absurd.

It's just there for completeness. The default is 'use default'. If you'd set both devices to the same error correction parameters and tell them /not/ to negotiate, they'll just run along happily...

...although I _am_ thinking about turning on CRC by default.

A single bit error in the negotiation could lead to an inoperable connection. One expects even parity and the other expects odd. In such a situation, neither party will accept any message from the other including Reset Device.

I'll include some 'default defaults' in the next draft :^)

Data integrity is not something that can be negotiated: It must be an integral part of the protocol.

Hm, while I _do_ have a personal dislike for non-layered systems, I think you're partially right. I'm not going to force it down any throats, however.

Thanks for your cricitcism -- it's much appreciated.