Proper digital audio interface - diyAudio
Go Back   Home > Forums > Source & Line > Digital Source

Digital Source Digital Players and Recorders: CD , SACD , Tape, Memory Card, etc.

Please consider donating to help us continue to serve you.

Ads on/off / Custom Title / More PMs / More album space / Advanced printing & mass image saving
Reply
 
Thread Tools Search this Thread
Old 14th November 2007, 11:53 PM   #1
diyAudio Member
 
Join Date: Nov 2007
Default Proper digital audio interface

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.
  Reply With Quote
Old 15th November 2007, 12:15 AM   #2
diyAudio Member
 
Join Date: Dec 2005
Location: Atlanta
So, how would you actually implement this?
__________________
He's not hi-fi, he's my stereo.
ShinyMetal
  Reply With Quote
Old 15th November 2007, 01:30 AM   #3
diyAudio Member
 
Join Date: Nov 2007
Using an MCU and some wits?
  Reply With Quote
Old 16th November 2007, 02:56 PM   #4
gmarsh is offline gmarsh  Canada
diyAudio Member
 
gmarsh's Avatar
 
Join Date: Apr 2004
Location: Halifax, NS, Canada
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.
  Reply With Quote
Old 16th November 2007, 03:48 PM   #5
diyAudio Member
 
Join Date: Nov 2007
Quote:
Originally posted by gmarsh
Problem #1: Practical implementation.


I thought it might be :)

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.
  Reply With Quote
Old 16th November 2007, 06:15 PM   #6
diyAudio Member
 
Join Date: Nov 2007
Done. I also added a padding facility to further cope with non-bit adressable interfaces.

Second draft
  Reply With Quote
Old 16th November 2007, 06:50 PM   #7
diyAudio Member
 
Join Date: Oct 2001
Location: .
Way too much spare time.
  Reply With Quote
Old 16th November 2007, 07:40 PM   #8
whatsup is offline whatsup  United States
Banned
 
Join Date: Aug 2007
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
Quote:
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.
  Reply With Quote
Old 16th November 2007, 09:27 PM   #9
diyAudio Member
 
Join Date: Oct 2004
Quote:
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).
  Reply With Quote
Old 17th November 2007, 06:41 AM   #10
diyAudio Member
 
Join Date: Nov 2007
Quote:
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.

Quote:
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...

Quote:
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.

Quote:
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...

Quote:
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.

Quote:
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 :^)

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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.

Quote:
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 :)

Quote:
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.

Quote:
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 :^)

Quote:
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.
  Reply With Quote

Reply


Hide this!Advertise here!
Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are Off
Pingbacks are Off
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
digital interface transformer,help tomat Digital Line Level 3 4th June 2009 05:10 AM
dat-link+ digital audio interface need help koko Digital Source 0 10th January 2008 09:07 AM
Digital Interface for 5.1 Channels Decoded Audio jgab Digital Source 0 16th July 2004 02:52 PM
digital audio interface inside a discman takashi Digital Source 2 4th March 2003 02:22 PM
digital interface higrade Digital Source 3 16th January 2003 12:35 AM


New To Site? Need Help?

All times are GMT. The time now is 06:55 PM.


vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2014 DragonByte Technologies Ltd.
Copyright ©1999-2014 diyAudio

Content Relevant URLs by vBSEO 3.3.2