Audio over TCP/IP using a Papilio One - Page 1
Forum section: electronics / projects

author: Fantasma25
author_rank: Regular Contributor
timestamp: June 21, 2014, 03:29:52 pm
content: Hello. I'm currently working on a project consisting on transmitting and receiving two channels of audio over the TCP/IP protocol. This is also known as a "digital snake" in the audio industry. Anyway... I currently have the ADC and the Ethernet part (almost) ready to prototype, but I will appreciate if you could take a look at it and give me your opinion.. As an ADC I'm using a TI PCM1807 with a PLL1705 to generate the sampling clock. It is a 2 channel 96kHz 24-bit ADC. As the ethernet controller, I'm planning to use a Microchip ENC28J60 because it seemd to be "easy" to use. The FPGA board is a Papilio One with a Spartan 3E 250K. I decided to go for an FPGA instead of a microcontroller because if I ever wanted to send/receive more channels, I could benefit from its massive parallelism. I'm planning on doing all the TCP/IP packing and unpacking inside the FPGA.Thanks!!

author: Scrts
author_rank: Frequent Contributor
timestamp: June 21, 2014, 03:46:10 pm
content: You sure you don't want to go for UDP/RTP? TCP/IP on FPGA is too difficult to do. I'd recommend to go for 10/100 Mbps PHY, implement ethernet MAC on the FPGA and do the audio transmission using UDP as it is commonly done in broadcast tv environment.

author: Fantasma25
author_rank: Regular Contributor
timestamp: June 21, 2014, 03:57:25 pm
content: Quote from: Scrts on June 21, 2014, 03:46:10 pmYes, I actually said TCP/IP referring to a network protocol, but since this is real time data streamming and low latency is waay more important than "reliable data transfer" (not that that is not important), I was planning on using UDP instead of TCP, but thanks for the advice!!

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 21, 2014, 06:38:38 pm
content: I remain dubious about sending high channel count audio over the "regular venue" switched network. A dedicated network (or simply end-to-end cable run) seem far more reliable.I have thought that an arrangement with 8 (or 16 or 24) of a THAT 5173 controlled mic preamp like the Innersonix Lucidity and running over an ordinary Cat5 cable would be a killer product.THAT 5173 Digitally Programmable Gain Controller IChttp://www.thatcorp.com/5173_Digital_Preamplifier_Controller_ICs.shtmlInnersonix Lucidity Digitally-controlled Mic Preamphttp://diy.innersonix.com/shop/lucidity-preamp

author: Fantasma25
author_rank: Regular Contributor
timestamp: June 21, 2014, 11:10:33 pm
content: Quote from: Richard Crowley on June 21, 2014, 06:38:38 pmI agree with you. I'm doing this with the idea that people will use it with direct connection or maybe with one dedicated high end switch.Quote from: Richard Crowley on June 21, 2014, 06:38:38 pmThat is a really cool idea! Some nice features like a good preamp may make this much more than just an audio snake. Thanks!

author: andtfoot
author_rank: Unknown
timestamp: June 21, 2014, 11:29:23 pm
content: I don't know how much detailed information they release, but look up Audinate Dante.In the pro AV world, it's one of the more popular ways of transferring live audio over networks without needing special switches (unlike another big contender, AVB).

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 21, 2014, 11:33:37 pm
content: Virtually all of those "pro" digital audio protocols (including Dante) require hefty payment and/or joining the "club" in order to access the specifications. The kind of payments required put them WAY out of the range of hobby activities.

author: Fantasma25
author_rank: Regular Contributor
timestamp: June 21, 2014, 11:48:53 pm
content: Quote from: andtfoot on June 21, 2014, 11:29:23 pmActually Dante was the thing that motivated me to do this. My ultimate goal (which is a quite ambitious one) is to make a cheaper and open source alternative for audio networking.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 21, 2014, 11:50:48 pm
content: Quote from: Fantasma25 on June 21, 2014, 11:48:53 pmGo for it! Let me know if you need some collaborators or beta testers. I am very interested in the same thing.

author: Fantasma25
author_rank: Regular Contributor
timestamp: June 21, 2014, 11:53:07 pm
content: Quote from: Richard Crowley on June 21, 2014, 11:50:48 pmCool!!! Thanks a lot!

author: David_AVD
author_rank: Super Contributor
timestamp: June 21, 2014, 11:55:16 pm
content: I've recently been looking at the range of audio-over-IP gear from Barix. How well it works over a mixed network remains to be seen.

author: Fantasma25
author_rank: Regular Contributor
timestamp: June 22, 2014, 12:46:29 am
content: Quote from: David_AVD on June 21, 2014, 11:55:16 pmIt does look interesting. They seem to have a lot of features!

author: Someone
author_rank: Super Contributor
timestamp: June 22, 2014, 01:28:16 am
content: Cheapest implementation of Audio over IP has been Cirrus logics Cobranet chips:http://www.digikey.com/product-detail/en/CS181012-CQZR/CS181012-CQZR-ND/2036609There is a lille bit of pricing elasticity going up to 16 channels or down to 2 channels. You'll be hard pressed to beat that solution with an FPGA, but it like all the other products locks you in to a specific protocol/ecosystem.

author: Fantasma25
author_rank: Regular Contributor
timestamp: June 22, 2014, 02:08:05 am
content: Quote from: Someone on June 22, 2014, 01:28:16 amWell... I wasn't expecting that XD It does seem to be a killer chip and CobraNet looks really cool. Thanks for the info!

author: linux-works
author_rank: Super Contributor
timestamp: June 22, 2014, 08:22:22 pm
content: I would not go the pure hardware route, myself. software gives so much more flexibility.I'm a networking guy, by trade, and switching/routing is something I do for my day job.QOS would be one way to prioritize the traffic. carving out tunnels or 'flows' would be another.I like the idea of having multiple channels open, monitoring them and actively picking the fastest one (or few) and bonding them together. with software, you can do that. with hardware, not so easy.as long as you can tolerate buffering a bit, software is the way to go. if you can't tolerate latency or buffering, you have no choice but to throw lots of bandwidth or dedicated lines at this.

author: madires
author_rank: Super Contributor
timestamp: June 22, 2014, 08:50:53 pm
content: For Ethernet I'd recommend to implement CoS to allow frame prioritisation by the switches. For the IP layer DiffServ would be nice. And you don't need "high end" switches. Today, even dumb and unmanagable desktop switches support CoS.

author: linux-works
author_rank: Super Contributor
timestamp: June 22, 2014, 09:38:42 pm
content: also, what is the distance? could this be all-LAN or is WAN needed? can radio be used?

author: Someone
author_rank: Super Contributor
timestamp: June 22, 2014, 11:41:47 pm
content: Quote from: linux-works on June 22, 2014, 08:22:22 pmTrying to maintain time(code) synchronisation between the points of the network is much harder than you imagine, audio dropouts/inserts/slewing is very obtrusive so the codec clocks all need to be synchronised. Dedicated hardware is used to provide the agile clocks which aren't present in other audio designs even if the feedback is all done in software.

author: linux-works
author_rank: Super Contributor
timestamp: June 23, 2014, 12:23:51 am
content: and that's why I said 'buffering'. with buffering and network time that you can trust, it can be done in software. pretty sure..but if buffering is not tolerated in the requirements, then you can't take this easy way out.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 23, 2014, 12:45:46 am
content: You can tolerate that kind of latency if you are only audio recording, or radio broadcasting, etc. But if you need anything remotely resembling "real-time" (like live sound reinforcement) or A/V sync (like video production) that kind of latency and unpredictability is a show-stopper.

author: Marco
author_rank: Super Contributor
timestamp: June 23, 2014, 12:53:11 am
content: We're talking about audio here and latency's in the range of ms ... you don't need hardware for that.On a 50 MIPS microcontroller you can run 5000 instructions before you use even 10% of the lowest latency budget cobranet has ...

author: Someone
author_rank: Super Contributor
timestamp: June 23, 2014, 08:50:28 am
content: Quote from: linux-works on June 23, 2014, 12:23:51 amThe clocks of the ADC and DAC wont be synchronised, so how do you make up for drift/accuracy in their oscillators as you eat through the buffer? Glitching by dropping or adding dummy samples wont be pleasant.Quote from: Marco on June 23, 2014, 12:53:11 amYou do need hardware, but feel free to show the world how to synchronise digital media on remote oscillators running with arbitrary frequency offsets. Its a fundamental issue of digital broadcast/transmission systems.

author: Rasz
author_rank: Super Contributor
timestamp: June 23, 2014, 08:55:06 am
content: I dont think papilio is the correct platform for you.XCORE (cant believe I actually recommend id) is basically designed to do this kind of crap.Dev board (startkit) is only $15. Ethernet PHY dev board is another ~$15, for example LAN8720/DP83848 on ebay.https://www.xmos.com/buy#StarterKitshttp://www.ebay.com/itm/DP83848-Ethernet-Physical-Transceiver-RJ45-connector-control-interface-Board-Kit-/310812717291?pt=LH_DefaultDomain_0&hash=item485de1b0ebhttp://www.ebay.com/itm/High-Performance-10-100-Physical-Layer-Transceiver-LAN8720-Ethernet-Module-Kit-/261479108838?pt=LH_DefaultDomain_0&hash=item3ce15e90e6Bare xcore chips start from ~$3.5 for easy to solder smd package, ethernet phy chips start at $1.https://github.com/xcore/sc_ethernethttps://github.com/xcore/sc_xtcphttps://github.com/xcore/sc_i2sand you are done.Xcore is what pro audio gear uses. You get 500 MHz mips soc with dedicated serializers/deserializers/buffers to do bitbanging/bitstreaming.

author: Marco
author_rank: Super Contributor
timestamp: June 23, 2014, 09:47:37 am
content: Piecewise Polynomial interpolation is cheap, just need to come up with some buzzwords in case you have to sell it to an audiofreak.

author: Jeroen3
author_rank: Super Contributor
timestamp: June 23, 2014, 02:14:02 pm
content: Audio isn't that fast that you'd need an fpga do work with it.Find some microcontrollers with I2S and MAC (ethernet) and create your very own gigabit* network connection.Unless there is need for compression...*Or Fast Ethernet

author: ehughes
author_rank: Frequent Contributor
timestamp: June 23, 2014, 05:10:18 pm
content: You might want to better understand your audio application before you apply TCP/IP to it. IP networks are not the best solution for real time, low latency audio. They simple were designed for other purposes. If this is for a real show then TCP/IP is a bad idea. The latency will kill it. A common thought is that "what is a few milliseconds?". The problem is that everyone at every stage likes to add a few milliseconds and then any sense of real time is killed.The other issue is of network setup. If it requires any setup beyond just plugging it in, it is a show stopper. The use model should be plug in both and and get audio. No configuration.I have seen a lot of "network" audio gear for sound reproduction come and go because of these 2 issues.The audio clock drift that others have mentioned is a big deal. Protocols such as AES3 solve it by encoding a master clock in the signal. To be honest, you might be better looking at something like that as is a known working solution.AES-3 would get you a stereo signal over a single pair of wires (used in pro recording studios) without the latency. LOTS of chipsets to take I2S and create AES3. Drift, etc is handled byt the encoding and PLLs at either end.MADI (AES-10) gets use 64 channels (FPGA would be required)http://en.wikipedia.org/wiki/MADIAlso, see this:http://en.wikipedia.org/wiki/AES47http://en.wikipedia.org/wiki/AES52Lastly, Gibson has a free spec called MAGIC that transports over ethernet:http://en.wikipedia.org/wiki/Gibson_MaGICIt has its own transport (packets are raw ethernet with custom data, not IP packets).MAGIC is dead. Same issues as described before. No one wants an instrument with latency and requires configuration. You need to plug it and and just work without ANY configuration.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 23, 2014, 05:40:34 pm
content: As someone who has been involved with BOTH live audio AND electronics for 50 years, I fully agree with ehuges.All of those audio over TCP/IP look OK on paper, but they don't deliver in the heat of battle.Now, audio (even multi-track) over Cat-5 cable is a very DIFFERENT matter.Building myself a "digital snake" is on my long-term project list.And as long as we are talking about digital, those digitally-controlled mic preamps seem like a perfect complement:Texas Instruments PGA 2500http://www.ti.com/product/pga2500THAT 1570/5173http://www.thatcorp.com/5173_Digital_Preamplifier_Controller_ICs.shtml

author: linux-works
author_rank: Super Contributor
timestamp: June 24, 2014, 12:06:21 am
content: aes3 (aka, spdif) does not solve any clocking issue! in fact, there is no distributed master clock, the clock is embedded in the data (which a lot of people hate).spdif also can't go long distance (aes/ebu or aes3; same thing).i2s is not a long haul proto, either; its inside-box only, not between-box.

author: ehughes
author_rank: Frequent Contributor
timestamp: June 24, 2014, 02:17:17 am
content: Quote from: linux-works on June 24, 2014, 12:06:21 amJust to be precise, AES3 and SPDIF are NOT the same thing. They share similar protocols but differ on physical interface. This is is something anyone who has built circuits with AES3 would understand. Sony took the protocol and applied it to junk optical cable and/or RCAhttp://www.aes.org/publications/standards/search.cfm?docID=13http://en.wikipedia.org/wiki/AES3AES 3 (IEC 60958 Type I) — Balanced line, transformer coupled --> XLR . .... I have successfully gotten a 300 meter run. I am not sure you would call that a short connection. It is used in studios *everywhere*.I would have to disagree on the clocking statement. I can recover an ADC's MCLK easily over AES3. While it is not a true single clock (which in itself is a somewhat ridiculous design requirement) for everything, it is the next best thing. If I have a group of recovered MCLK's I can do whatever I need.If you want a magical system that can distribute one clock to everything in a system across a large geography, there are some physics problems. Systems such as AES3 have solved this problem in the the most practical way possible (and lowest cost). Simple transmit a local ADCs clock in a signal and have the receiver deal with it. I have not personally seen any field proven alternative. Not saying they don't exist, but the market has determined it to be a "low energy" (in the Rayliegh-Ritz sense) solution to the problem.That all being said, it is fun to play with. You definitely know when you audio circuit works :-)

author: linux-works
author_rank: Super Contributor
timestamp: June 24, 2014, 02:54:52 am
content: aes and spdif really are the same, the diff are minor and subtle.spdif technically is half a volt and aes/ebu (now, aes3) defines something closer to 5v. 75ohms coax for spdif, toslink for opto 'spdif' and balanced 110ohm, usually (but not always) over xlr for aes. but those are physical layers; the logical layer is the same aside from consumer vs pro (scms bits on consumer, other header bits for pro).but at the logical level, its still embedded clock and that is problematic. I don't fully understand the corner case, but there are some cases where encoding to spdif and back again is not transparent. I've never run into it, but I think I recall some strange case where spdif does not become fully mirror encode/decode.also, the longer you run the cable, the more the impedance matching becomes important. if you don't have precise match, you get reflections and these can interfere with proper bit extraction. usually the receivers can tolerate a lot of reflection voltage but its still something that engineers try their best to avoid.I don't have a problem with spdif; but a current trend is to send i2s directly from a computer or streamer and have that go to a DAC, rather than using spdif as the player->dac interface. if there was no issue with spdif, there would be no reason for this extra effort in avoiding spdif. again, I don't avoid it, I think spdif is great for short runs and is the right thing for inter-box comms; but many audio engineers avoid spdif like the plague and I suspect there are reasons for it, even if they are infrequent corner cases.also, if you run 24/192, that does have issues with longer cable runs. the aes3 spec is in the process of some revsions (I have a review copy, not public, though) to solve this very problem.

author: NiHaoMike
author_rank: Super Contributor
timestamp: June 24, 2014, 03:07:44 am
content: Quote from: ehughes on June 24, 2014, 02:17:17 amFiber isn't junk. It's superior to copper in almost every respect except cost, robustness, and ease of repair.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 24, 2014, 04:11:25 am
content: TOSLINK is the very cheapest form of optical "fiber" that could possibly exist.Indeed, fiber isn't "junk". But TOSLINK is as close as you can get to junk optical.

author: ve7xen
author_rank: Super Contributor
timestamp: June 24, 2014, 04:58:32 am
content: Quote from: Someone on June 23, 2014, 08:50:28 amYou resample to a medium-term average of the incoming sample clock. If your sample clocks are reasonably close to each other you won't need much buffer at all to make this work. Of course, like the much maligned USB Audio Class, your output sample clock now depends on the jitter properties of the transport, which is probably less than ideal, though likely doesn't cause any measurable problem. This problem is a pain in the ass, but except for truly synchronous systems, it's been solved time and again, there's even asynchronous resampling hardware available to do this for you.You could also use RFC1588 or SyncE to accurately synchronize to the master clock. Hardware timestampling is pretty commonly found in merchant PHYs these days. This is commonly used in telecom gear which also has tight timing requirements, and it works fine. If you use good clocks you can probably push this to only buffer a single sample, but may require a brief synchronization period when first connected to achieve that.If you're targeting a point-to-point setup that just nominally uses "Ethernet" and you don't care if it works with commodity Ethernet equipment, then you could also probably exploit the common-mode path down the cable to transmit a master clock which is synchronized to the transmitted audio frames. I don't see any reason that commodity Ethernet wouldn't work though, you'll add a tiny bit of latency but any modern gear should be fine for audio use if you design the protocol and hardware properly.Take a look at how netjack does this. It's a full software solution, but must tackle many of the same problems as your proposal would. As-is I'm sure it's not usable in anger, but there may be some useful tidbits in their solutions.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 24, 2014, 06:59:18 am
content: I have to chuckle when I see audio people worried about carrying AES/EBU/SPDIF over long distances cleanly. Why we are talking about bandwidths of 3 Mbit/s!Meanwhile, I routinely run HD-SDI (1.5 GBit/s) over 300ft (100m) coaxial cables for my six cameras. And people run HD-SDI (SMPTE292M) even over Cat6 UTP cable.http://en.wikipedia.org/wiki/List_of_device_bandwidths#Digital_audiohttp://en.wikipedia.org/wiki/List_of_device_bandwidths#Digital_video_interconnects

author: madires
author_rank: Super Contributor
timestamp: June 24, 2014, 12:29:43 pm
content: Quote from: Richard Crowley on June 24, 2014, 04:11:25 amMost TOSLINK patch cables use cheap 1mm plastic fiber. It's not OM4

author: madires
author_rank: Super Contributor
timestamp: June 24, 2014, 12:42:30 pm
content: Quote from: Richard Crowley on June 24, 2014, 06:59:18 amMe tooAn standard telephone cable (2*2 TP, foiled) is rated Cat 3, i.e. good enough for 10BaseT.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 24, 2014, 01:31:31 pm
content: Quote from: madires on June 24, 2014, 12:29:43 pmMy understanding is that it is actually extruded and not a drawn fiber at all. That is why it is limited to 3ft / 1m.

author: linux-works
author_rank: Super Contributor
timestamp: June 24, 2014, 02:28:45 pm
content: Quote from: madires on June 24, 2014, 12:42:30 pmtl;dr answer for you: data is not audio.10baseT also has timeouts, retries and checksums (well, tcp does, which is what most folks use; and even udp has apps that do the reliability layer for you). audio has no retries, no timeouts and also embeds control timing IN the signal.its different.as for the 3mhz comment, you need a LOT more than 3mhz since these are square waves and edges do count. you need several times the 3mhz bw to correctly send sq waves thru.

author: linux-works
author_rank: Super Contributor
timestamp: June 24, 2014, 02:29:32 pm
content: Quote from: Richard Crowley on June 24, 2014, 06:59:18 amso, when is 24/192 3mhz?answer: it isn't!

author: linux-works
author_rank: Super Contributor
timestamp: June 24, 2014, 02:32:31 pm
content: Quote from: NiHaoMike on June 24, 2014, 03:07:44 amspdif audio does not run over glass fiber, its plastic. some early companies tried to use att glass fiber blocks and cables but it was not the proper thing from the aes/spdif spec.plastic fiber does create more jitter (the tx/rx blocks, more, iirc). but I still do like fiber as it does not have reflections and does not need trafos for isolation (coax should have a pulse trafo on both tx and rx sides and that adds cost and lower end trafos suppsedly affect the audio; core isolation, capacitance being 2 issues with trafos for digital audio use).

author: madires
author_rank: Super Contributor
timestamp: June 24, 2014, 03:19:20 pm
content: Quote from: linux-works on June 24, 2014, 02:28:45 pmIsn't digital audio data? It doen't matter if you transport the audio data directly via a bus, a wire, an optical connection or some other method as long as the other end receives the audio data within specs (maximum delay, jitter and so on). Even if you connect the receiver directly via a parallel bus on the same PCB you'll have delays, jitters and what have you, caused by the bus and the processing by the ICs involved.QuoteIt also depends on the encoding. If you encode 3Mbit/s in a way that requires just 1MHz bandwidth you also reduce the bandwidth requirements for the wire.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 24, 2014, 04:02:56 pm
content: Quote from: linux-works on June 24, 2014, 02:28:45 pmBut digital audio is "data".QuoteYes, and the difference between a real-time bitstream of data (whether audio or video) vs. a packet-based messaging system is the basis of this whole discussion. Thanks for the summary.QuoteAnd my 1.5 Gbit/s doesn't have exactly the same requirements? That "argument" seems like a complete wash.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 24, 2014, 04:14:45 pm
content: Quote from: linux-works on June 24, 2014, 02:32:31 pmWell, no. The bitstream is called "TOSLINK" when using optical transmission, and "S/PDIF" when using copper. It is exactly the same bitstream and conversion between TOSLINK and S/PDIF is trivial in the original sense of the word.Toshiba was the originator of TOSLINK, and Sony and Phillips co-developed S/PDIF. You can see the comany initials in the names.There are adapters to use real glass fiber cables with TOSLINK. Those are used to greatly extend the working distance over the super-cheap extruded plastic stuff originally developed for TOSLINK which was typically 1m or less.QuotePoor circuit design causes jitter. Blaming the transmission medium is just an excuse for sloppy/cheap design 20 years ago.

author: ehughes
author_rank: Frequent Contributor
timestamp: June 25, 2014, 12:41:14 am
content: QuoteNope..... It is a biphase code (differential manchester) which is just a simple case of FSK. You can do with just sine waves.a.) A proper receiver does not expect a square waveb.) The input PLL does not care about a human's perception of a square wave. It is simple FSK demodulation. All that matters is adequate bandwidth for the FSK and a decent SNR. This is information theory 101c.) the transformer coupled, balanced line doesnt care about square waves.Find anything using a biphase mark code and you will quickly see that you absolutely do not need a square wave.No.... I repeat communications channel with frequency/phase symbols require square waves. All the "digital" high bitrate stuff (HDMI, SATA, etc) care about are*SYMBOLS*.People really need to stop thinking about "digital" and rethink "symbols". Symbols in a communications channel are not represented by square waves (they make pretty pictures for illustration but that is about it). Ethernet is no different.Pull up a datasheet for any ethernet PHY and you will see the output stage really isn't concerned at all about an edge of a square wave. It is all analog at that point....I design with this one this one:http://www.ti.com/product/dp83848-epTOSLink is the "junk" cable I was referring to. It's dispersion is awful is the #1 reason people think that encoding a clock in a signal is an issue. The group delay distortion wreaks havoc on the receiver trying to recover the clock. I have personally never experience any issues with a decent circuit and/or medium. A biphase Mark over copper is about as good as it gets for this application.Now what would be really interesting is something new using OFDM and an FPGA....I don't understand the impedance comments. A 110 Ohm line with termination will yield no reflections. I don't care if it is 1 meter or a hundred. This is just E&M...

author: Someone
author_rank: Super Contributor
timestamp: June 25, 2014, 01:28:05 am
content: Quote from: ve7xen on June 24, 2014, 04:58:32 amNone of that gets the output DAC clock synchronised with the source/master, consumer hardware rarely supports operating as a slave let alone a variable frequency local clock. Resampling the stream to a different and almost identical local sampling frequency is not a cheap mathematical process and will trash high frequency content, there might be a day when this is a cheaper and better solution to having local disciplined clock but we aren't even close yet.The real solutions using a disciplined clock and the associated hardware will output the same bit stream you pass into them (barring packet loss) with an unchanging (even configurable) fixed latency.If these characteristics aren't important then by all means use some sort of stream casting, embedded in all the internet radio receivers you see. But its completely different to having an audio stream transported across IP from an ADC to a DAC. The op started out with "digital snake" as their reference, not some radio toy, software does not cut it.

author: SirNick
author_rank: Frequent Contributor
timestamp: June 25, 2014, 01:59:04 am
content: That's something I've never understood about Internet radio, or even satellite TV (or radio) for that matter. Is it just assumed that at some point the buffer will over/under-flow? Is it standard practice to stuff or drop samples in a dithered manner to keep buffers at average levels? Or is there a way of recovering a reasonable clock signal through an indeterminate (variable-latency) media like The Interwebs?This one has puzzled me for a while.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 25, 2014, 02:18:43 am
content: Even back in the analog era, TV stations had a "master sync" generator that everything (from the cameras all the way out to the transmitter) was clocked/synced to. Network (or any remote) video that came in from outside was "frame-synced" to local master sync. If that involves dropping a whole frame (or duplicating one) every few minutes, then so be it. Nobody will know or care. And it is so much easier now in the digital era. Everything you see on the air (or satellite or cable, etc.) is essentially playing out of a video port on a computer.And audio/radio is even easier. There isn't any need to synchronize everything to 1/30th (or 1/25th) of a second (one frame of video). Nobody (including the "golden ears" is going to detect or care about a dropped or duplicated sample here and there. This is the Real World, we can on with our lives and worry about more important things.Furthermore, it is very rare that you are watching something from far away that wasn't pre-recorded into a file before you saw it. I'm watching high-definition video of some guys kicking around a ball down in south america somewhere and the picture quality is stunning, but it breaks up a few times an hour just to remind us that it is coming from 1000s of miles away on the other side of the planet.And further even more, places where it REALLY matters can synchronize their clocks to GPS, so there is virtually zero buffer over/under-run.

author: Someone
author_rank: Super Contributor
timestamp: June 25, 2014, 02:42:44 am
content: Quote from: Richard Crowley on June 25, 2014, 02:18:43 amYou still genlock a digital studio or broadcast chain, each device aligns its internal clock to a master somewhere. Just that its easy to recover the clock from the SDI stream (and then offset your cameras internal framer to align with all the slight delays heading back to the mixer/switcher). The computer (or hardware device) playing back the source material might be the master or it might be genlocked to something else. Also of note is that consumer DVB receivers have been in many ways a step back in image quality from analog broadcasts, breakup and sync issues are now "normal".Quote from: Richard Crowley on June 25, 2014, 02:18:43 amThat depends if there is a reference audible or visible from the transmitting side, two consumer examples:HDMI projector and surround sound system playing back a movie, audio to video synchronisation worse than a few ms is noticeable.Playing music in one room through some speakers and piping it to another to play the same sound, where you can hear both sets of speakers. Microseconds can cause audible differences in this situation, much more so if that latency is changing and not static.And those are just two common consumer applications! If you're all going to keep going on about how an elastic buffer and some software can produce accurate audio reception I'll just go back to lurking.

author: SirNick
author_rank: Frequent Contributor
timestamp: June 25, 2014, 03:20:57 am
content: I wouldn't suggest that at all. Buffers don't fix mismatched sync, they just change the frequency (and possibly duration) of errors. That's why I asked how you're supposed to keep distributed systems in-sync.From RC's description, it sounds like the best you can do is shoot for the tightest clock tolerance you can reasonably afford, and accept the periodic slips as a necessary evil. From a consumer's standpoint, that's a secret that is kept pretty firmly swept under the rug. Interesting.

author: Richard Crowley
author_rank: Super Contributor
timestamp: June 25, 2014, 06:24:13 am
content: We have been struggling with audio/video sync problems since the dawn of digital video. The problem is that the digital video and digital audio data get different treatment at several points in the distribution chain even up to the TV screen you are watching. A/V sync is a different problem than frame-sync and genlock and master-clock.

author: madires
author_rank: Super Contributor
timestamp: June 25, 2014, 01:07:40 pm
content: Quote from: SirNick on June 25, 2014, 01:59:04 amIf buffers are used the receiver collects some packets/frames and starts the playback a little bit delayed. That way the buffering compensates for jitters. If there's a congestion or a network problem and the buffer is emptied, the receiver might give you a warning message or simply displays the last frame. That's based on how the handling of an empty buffer is designed. A buffer overflow won't happen for broadcasting, since the packets are sent with the throughput of the data source, i.e. they can only be in time, late or lost. For video-on-demand you can get more data than required for playback, but in that case there's a buffer management taking care about that. Why would you need a clock signal from the TV/radio station? But if you like to synchronize system clocks you can use ntp for example. For higher accuracy you would use GPS or something like DCF77 (radio clock service in Germany).

author: ve7xen
author_rank: Super Contributor
timestamp: June 26, 2014, 04:16:03 pm
content: Quote from: Someone on June 25, 2014, 01:28:05 amDid you miss the part where I said "sync the clocks"? Resampling is one option, it is somewhat "expensive" but can be done in hardware with minimal delay and practically zero distortion, e.g. SRC4192 and is the easy way out for the 99% case. If you need synced clock, you can do it in the ways I described in my post.QuoteRight. I see no reason you can't build such a system on top of Ethernet, and described several ways to accomplish just that in my post.QuoteAs far as I can tell there are two big audio issues professionals care about that "radio toys' do not; latency and sample clock sync. Clock quality is of course also important, but that's just a matter of buying a good clock. Ethernet is no more lossy than any other digital medium, which is to say that it's for all intents and purposes lossless. You're acting like these are impossible to achieve over Ethernet, which I don't believe is the case. I did not specify a software-only solution, you do need hardware to sync the clocks properly if you're going to do it that way, but this hardware is widely available in commodity Ethernet PHYs.QuoteFor the same reason you need one in an audio system. If the clocks are not exactly synced, no matter the size of your buffer you will inevitably over or underflow, unless you get really lucky with drift direction. I think for consumer streaming this is just left unhandled and the occasional dropout is considered acceptable. They just use large buffers to make it unlikely. In theory, for modern FTTx deployments I guess they could sync clocks all the way to the playback device at the customer premise, provided it's connected directly to provider equipment ('triple play' services, not web).

author: madires
author_rank: Super Contributor
timestamp: June 26, 2014, 06:07:39 pm
content: Quote from: ve7xen on June 26, 2014, 04:16:03 pmThe receiver just needs to know that the audio stream is 16 bits at 48kHz for example. If you select the audio stream the receiver will buffer some amount of bytes before it starts to play. So it can't be synced to the radio station anyway, just to the playback rate. The receiver simply fetches the next sample from the buffer at 48kHz and plays it. Synchronizing to a central clock source is necessary if you multiplex several data streams and have to hit a specific timeslot (e.g. PDH/SDH) but not for playback of some audio/video stream. Or have I misunderstood you?

author: Someone
author_rank: Super Contributor
timestamp: June 27, 2014, 05:46:38 am
content: Quote from: ve7xen on June 26, 2014, 04:16:03 pmOpening withQuote from: Someone on June 25, 2014, 01:28:05 amRFC1588 can be used for synchronisation at all sorts of different precisions, having a local disciplined oscillator is essential to get the sample rate lock.Quote from: ve7xen on June 26, 2014, 04:16:03 pmWe agree its entirely possible to do over ethernet, but it needs dedicated hardware resources with a disciplined oscillator. Your post just walked down the middle and wasn't very clear that a 100% software solution is not comparable to the hardware systems that already solve this problem.

author: Fantasma25
author_rank: Regular Contributor
timestamp: June 27, 2014, 05:58:32 pm
content: All right then... This was fun! You pointed out a lot important and interesting stuff. Maybe it is a little bit overkill to use an FPGA to transmit only a stereo signal (for now), but with a higher channel count it's going to be easier to design without recurring to "high speed" digital design issues. And yes, there are a some inexpensive of ASICs that do all the hard work for you, but there are not nearly as flexible as an FPGA. And I'll most likely run into timing and sync issues, but hey, if it was easy, it wouldn't be any fun! XD And besides, it has been done before, so it is possible.And also, I'm kind of a n00b in this field (I'm an EE undergraduate) so even if it doesn't work, I'll learn a lot out of it.

author: SirNick
author_rank: Frequent Contributor
timestamp: June 27, 2014, 10:30:28 pm
content: Quote from: madires on June 26, 2014, 06:07:39 pmNo, unfortunately, this is a naive view of the reality of clocking digital audio. I don't mean offense by that, you're just missing the simple fact that no clock is exactly 48.000000kHz. If you have a 48kHz transmitter, and a 48kHz receiver, each slaved to its own internal sample clock, the two will eventually fall out of sync with each other. This will be a periodic error, assuming no changes in drift due to temp or other external influences. Having a large buffer will delay the first occurrence of the error, but it will not prevent it, nor will it prevent the cyclic reappearance of that error.Case in point: I had two identical audio interfaces (Presonus Digimax FS -- 8 analog in, ADAT out) and forgot to set the second as a clock slave. I recorded a friend of mine noodling around on his guitar, mic'd on the second interface. The first interface was providing the ADAT clock, so the PC-to-Lightpipe box and the first audio interface were synced fine. But, since the only actively recording track was on the un-synced second interface, you got this nice digital SSSKKKRREEETTCH every 30 seconds or so, when the two drifted in and out of sync. Lovely. Now consider, that was two identical rack units right next to each other, same power, same ambient temp. Think about the likelihood of perfect sync over a trip to a satellite and back.

author: Rasz
author_rank: Super Contributor
timestamp: June 28, 2014, 07:44:02 am
content: Quote from: Fantasma25 on June 27, 2014, 05:58:32 pmif you mean Xcore then no, its dedicated and build for this kind of work in mind, is easier to program and cheaper. You should at least get a starterkit and check it out, unless whole point of this build is to get familiar with fpga.

author: Marco
author_rank: Super Contributor
timestamp: June 28, 2014, 10:58:44 am
content: Quote from: SirNick on June 27, 2014, 10:30:28 pmAs I said before you can just use piecewise polynomial interpolation to reclock it digitally ... not perfect, but good enough for anywhere you aren't using a master clock to begin with. Just don't tell the audiofools you're using it.

author: madires
author_rank: Super Contributor
timestamp: June 28, 2014, 11:20:44 am
content: Quote from: SirNick on June 27, 2014, 10:30:28 pmThat's totally clear! I was talking about a radio/tv station streaming audio/tv via IP. Since there's no steady data stream the receiver can't simply sync on the data stream and has to rely on it's internal clock. But when you add a timestamp to each sample, it's possible to synchronize the receiver to compensate a drifting clock.QuoteThat's what I meant by multiplexing. For a synchronous data transport you need a master clock.

author: SirNick
author_rank: Frequent Contributor
timestamp: July 01, 2014, 07:27:12 pm
content: Quote from: madires on June 28, 2014, 11:20:44 amHm, so what good is a timestamp if the tx and rx sides don't have access to the same clock?Linear PCM samples are inherently time-stamped. Sample n is exactly 1/samp_rate seconds after sample n-1. The problem is knowing exactly how long that fraction of a second really is.Marco's correct though. This is a solvable problem by either using the buffer level to discipline a clock, or pad / strip samples. I just wasn't sure what was usually done in The Real World. E.g., you aren't going to discipline the sound card's clock on an Internet radio stream -- no access at that level. So you either live with buffer sync problems or cherry-pick samples as needed. For broadcast (digital radio, satellite, etc..) I didn't know if there was a master clock signal or if fudging was normal.

author: madires
author_rank: Super Contributor
timestamp: July 01, 2014, 08:48:20 pm
content: Quote from: SirNick on July 01, 2014, 07:27:12 pmOk, the sender adds a timestamp (based it's local clock) to each sample. When the receiver starts playing the received samples, it takes the timestamp of the first sample as reference and also notes the local time. For the next sample/timestamp the receiver takes the difference to the first one and compares that to the difference of the local timestamps. That way you can check if the local clock is drifting vs. the source. The local clock might be stable and the sender's clock drifting, but that doesn't matter because we synchronize to the sender's clock. Then you take the drifting offset and adjust your local clock to follow the sender's clock. That process is repeated as long as the receiver plays the stream.

author: NiHaoMike
author_rank: Super Contributor
timestamp: July 02, 2014, 12:29:55 am
content: You could slightly shorten or lengthen silent (or very quiet) segments and it would have next to no effect on perceived audio quality.

author: SirNick
author_rank: Frequent Contributor
timestamp: July 02, 2014, 01:11:24 am
content: Quote from: madires on July 01, 2014, 08:48:20 pmSo let's consider that approach:Now, from what I've seen, timestamps are ubiquitous in A/V synchronization. You're playing an MPEG file in VLC for instance (or a hardware player, it really doesn't matter). It parses the container format (the .mpg file, for e.g.), and pulls the audio and video stream out in packets. Each packet gets a timestamp before being sent through the respective codec chains. That way, regardless of the compressed format, length of packet, how many samples / frames it contains, or how much delay exists between the availability of the resulting decoded data streams, the end result is in sync relative to each other. However, in this case, the timestamp isn't pulled from a clock, but from the calculated duration of each packet of data -- regardless of whether the container format has the timestamp built-in or if it's fabricated by the player.But for just audio streams, there's nothing to be gained by timestamping samples. It could actually hurt more than help. Again, linear samples are inherently timestamped in that they have a defined duration. Adding a timestamp on top of that is redundant data. At best, it could be calculated on the RX side by simply counting the number of samples and the sample rate, so it adds nothing of value to the data. At worst, the resulting timestamp and calculation could disagree with each other (due to bugs, or blind trust in underlying container files that may have been cut, concatenated, or otherwise mangled), and then which do you trust?It's assumed that the TX side is going to play at what it thinks is perfect timing, so a 44kHz audio stream should play exactly 44,000 samples in exactly one second. If those two numbersdon'talign, then which is wrong -- the RTC or the sample clock? Same goes for the receive side, ultimately. Do you trust your local RTC, or do you assume that your playback hardware has a more accurate notion of time?Finally, it's just not precise enough to do any good. If you have transport latency that can vary at all, or if you're buffering, then the timestamp is relative to what? The moment the data packet arrives? The moment it's processed? Played? Can you guarantee less than one sample's resolution between when the TX hardware generated the sample and when it stamped that packet? Is the timestamp more granular than the sample rate? Is it a clean multiple, or will there be rounding errors? Regardless, it doesn't really tell you anything you don't already know by comparing the incoming data rate to the outgoing playback rate.If you see a hole in my argument, feel free to poke it. I enjoy the discussion, and recently finished writing my first media player implementation (well, finished a working prototype anyway...), so I've become acutely aware of (and fascinated by) all the little snags involved in maintaining data flow. It's deceptively complex to build a framework that makes no assumptions about the availability of data (seekable file, or linear stream?), the format of that data (can I always assume the incoming data packet size is less than or equal to the decoded samples?), the compatibility of formats (32-bit float samples at 44.1kHz where the hardware technically only consumes 16-bit, 48kHz) and so on. I always say: If you really want to understand something, write an implementation in software. What you don't know will become quite obvious in short order!

author: hamster_nz
author_rank: Super Contributor
timestamp: July 02, 2014, 02:26:45 am
content: I know nothing about this area, so these are just ideas.Wouldn't it be practical to have 2k sample elastic buffer / FIFO for each channel, and aim for them to be filled with 1k samples (for 48k channel this gives a 22ms delay). And of course you would have to adjust the depth depending on the nominal sample rate so the inter-channel skew is roughly constant.You then play back at a rate that can be tuned for each channel - maybe +/- a few times the maximum clock error you will see (e.g. at some frequency between 48,005 and 48,995 samples per second).As new packets arrive (approx 1500 bytes or 250 24-bit mono samples). you add them to the buffer. If the buffers are slightly empty you reduce your playback 'stride' a little, resampling a little sooner or if they are slightly full you increase the stride size a little, causing to to replay a smidgen faster.You could mute the channel until you have a good lock on the source (indicating by it ping/ponging between "faster/slower" with close to a 50% duty cycle. It would take a little bit of modeling in S/W at first to work at it's best.The quality of your resampling could be pretty high - as the samples come out of the buffer reconstruct at a higher rate (192kS? 384kS?, and then downsample to whatever output rate you want, using the local clock as the reference. FPGAs have DSP blocks for a reason :-)

author: hamster_nz
author_rank: Super Contributor
timestamp: July 02, 2014, 02:55:38 am
content: Quote from: SirNick on July 02, 2014, 01:11:24 am"Time is relative - lunchtime doubly so" - Douglas Adams.My feeling is that without any signal being more 'true' than any other you have to assume that your local clock is the most reliable one and all others are wrong. about the only thing you can assume is that the other clocks are pretty much regular (and if they are not then the samples most likely are not worth the electrons they are encoded with). It then just becomes a problem what is the technically best way to make up for the shortcomings of the other clocks.A crude way would be to drop or stuff extra samples every now and then to match your local clock. A better way is to process the incoming data to make it consistent with your clock, and then resample it. You should be able to do this with at most 0.5 LSB of error/noiseYou could test this by taking the resampled data, and then sampling it back against its original clock. Subtract one from the other and anything left behind is the error/noise that is introduced by the process. (Of course this only works if the process you used is symmetrical in time, causing no phase change).

author: SirNick
author_rank: Frequent Contributor
timestamp: July 02, 2014, 07:28:26 pm
content: I've never done research on clock alignment, but if I had to guess, using zero-crossing to stuff or drop samples would probably be a safe and simple approach. Your idea of up-sampling and decimating samples might produce cleaner results. You could even take two samples, average them and interpolate based on that. Dropping a sample would be as simple as taking two and producing the average of them. Adding a new one would be as simple as creating an in-between value. Seems simple enough.I would try to avoid any per-channel tricks though. You can easily tolerate minor timing anomalies, but inter-channel phase correlation should be preserved if possible. Imagine a multichannel interface with drum mics. Ideally, those mics are spaced such that any summing is phase-correlated. You're talking about way more than stereo here, so adjacent pairs aren't necessarily significant. An 8-channel interface should have lock step timing on all eight channels. Multiple interfaces should be ganged via word-clock. Is a difference of one or two samples going to upset something where the speed of sound is concerned? Probably not too much, that's a pretty small angle. Nonetheless, it should be possible to avoid disturbing it.As anyone else still reading this thread?Audio and engineering nerd here. Love this stuff.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 02, 2014, 11:33:46 pm
content: Quote from: SirNick on July 02, 2014, 07:28:26 pmStuffing/dropping (although easy) would be the wrong way to do it if you at all wanted to do it properlyImagine a 1.4V sine, at 1/4th the the sampling rate. If you end up sampling at about 45, 135, 225, at 315 degrees you will get:+1.0, +1.0, -1.0, -1.0, +1.0, +1.0, -1.0, -1.0......Lets just simply that to + + - - + + - - + + - -If you drop or stuff a sample, even if you average between the two you get+ + - - + - - + + - -or+ + - - + + + - - + + - -so anything with stored energy (e.g. the little bits in your ears that are happily waving at 1/4f) will find themselves 90 degrees out of phase, and having to adjust.Alternatively you could look at it as you have added enough energy into the signal in one hit to change it's phase by 90 degrees. That much 'energy' over that short a time could cause interesting effects during the DAC process...It's not as though it will be that big a problem, even at 96kS/s two +/- 20ppm crystals should only be out by at most four samples per second.Quote from: SirNick on July 02, 2014, 07:28:26 pmMight be just you and me!

author: Richard Crowley
author_rank: Super Contributor
timestamp: July 03, 2014, 04:42:15 am
content: We seem to be describing what the audio world has called "Sigma-Delta" modulation.http://en.wikipedia.org/wiki/Sigma_deltaThere are audio-specific forums where such topics are the primary focus. Some of them include the current or retired designers of audio gear we have all heard of and likely used before. For example GearSlutz, Group DIY, and DIY Audio, etc.

author: SirNick
author_rank: Frequent Contributor
timestamp: July 03, 2014, 07:00:13 pm
content: I had to stop going to Group DIY because I was finding myself tempted to build a legion of old signal processing hardware, when I already own emulating plug-ins and don't technically have any good reason to spend so much money on something I'll use maaaaaaybe once a year.I do still check in to DIY Audio from time to time, particularly when I get the urge to build an amp.Hamster -- I'm having trouble wrapping my head around the problem you're describing from the ASCII art. Are you saying you could cause phase reversals if you're unlucky enough to be discarding (or adding) samples in coincidence with the period of a sine? If so, wouldn't this prevent that kind of thing...?So, imagine sample 'n', which is the peak of a sine. You need to toss out this sample to avoid buffer overflow, so you take n-1, n, and n+1 and interpolate so you have two new samples, x1 and x2. You would throw n-1, n and n+1 away, then x1 would be something between n-1 and n, and x2 would be something between n and n+1. Even if the period of your interpolation happened to align with the peak of a sine, surely that would not be a particularly audible artifact? (After all, if the original signal has -1.0 to +1.0 transitions in the course of one to four samples, it's already a pretty crazy signal.)

author: hamster_nz
author_rank: Super Contributor
timestamp: July 03, 2014, 11:12:51 pm
content: Quote from: SirNick on July 03, 2014, 07:00:13 pmIf you have a pure sine wave, at say 4.8kHz, at a sample rate of 48kHz each each cycle takes 10 samples.If you drop in an extra sample, and then run a DFT on just those 11 samples (or just looped them over and over again) you get peak at 4.363kHz, plus all sorts of weird higher frequency harmoincs that it takes to make the pure sine wave look like a sine wave with an extra sample in it. It doesn't matter where you insert the sample (at +max, -max or zero crossing), the freqency components are pretty much the same, and frequency is what the ears are senstitive to.If you stretch out the DFT window to cover multple cycles you get a different peak closer to 4.8kHz, (e.g for 31 samples you get 4,645 Hz) and a different set of harmonics, but it still isn't a pure sine.If you were stuffing samples at one in 1000, to bring a 0.1% slow 48 kHz source clock up to speed you would end up with 999 cycles per second where the 4.8Kz signal sounds like a 4,804.8 Hz signal, and the remaining one cycle where it is 4,363 Hz, plus a small amount of noise extra every 1/48th of a second (which might even show up in the spectrum at 48 Hz).I am useless with frequency domain stuff and dbs, but at a really, really rough guess that gives you something like -60 db distortion @ 4.8kHz, and it not being very harmonic. Maybe somebody who can work MatLab can give a better figure.The I could rig it up on an FPGA with an I2S DAC and see... (or maybe you could try it in software by programatically editing a WAV file)

author: SirNick
author_rank: Frequent Contributor
timestamp: July 04, 2014, 12:00:05 am
content: Oh, I see. So it becomes a problem of noise shaping then -- to prevent the error from being so perfectly periodic, and potentially developing an audible signature. Thatwouldbe an interesting thing to model.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 07, 2014, 10:48:25 am
content: Quote from: SirNick on July 04, 2014, 12:00:05 amNot really, it is more a "don't stuff around with the signal, or you'll add frequencies into it that shouldn't be there".So here is code that up-samples by 8x, using 8 Multiply Accumulates (MACs) per point in the upsampled stream. If you were to 'cherry pick' the sample you want to interpolate between you don't have to convert them all, just pick the ones you need. You can safely interpolate as the signal contains frequencies under f/16 (as the original was f/2, and it has been upsampled 8x).The input looks like 1, 1, 1, -1, -1, -1, 1, 1, 1, -1, -1, -1.... the outputs looks likeAs you see it has no 'sharp corners' (and no high frequency components), and if the original sample rate was 48kHz, this would be a 8kHz signal, showing very little attenuation (the FIR filter is about 0.625f with 63 coefficients).The results are a little bit odd, because the input isn't a properly conditioned signal...Code:#include <stdio.h>#include <assert.h>#include <math.h>double lowpass_fir = {-0.000244141, -0.000488281, -0.000854492, -0.00146484, -0.002014160, -0.002319340, -0.001770020, 0.0000000,0.003417970, 0.008483890, 0.014587400, 0.02050780, 0.024231000, 0.023498500, 0.015930200, 0.0000000,-0.024353000, -0.055114700, -0.087585400, -0.11474600, -0.127930000, -0.118042000, -0.077026400, 0.0000000,0.113464000, 0.258362000, 0.424133000, 0.59576400, 0.755554000, 0.885559000, 0.970459000, 1.0000000,0.970459000, 0.885559000, 0.755554000, 0.59576400, 0.424133000, 0.258362000, 0.113464000, 0.0000000,-0.077026400, -0.118042000, -0.127930000, -0.11474600, -0.087585400, -0.055114700, -0.024353000, 0.0000000,0.015930200, 0.023498500, 0.024231000, 0.02050780, 0.014587400, 0.008483890, 0.003417970, 0.0000000,-0.001770020, -0.002319340, -0.002014160, -0.00146484, -0.000854492, -0.000488281, -0.000244141, 0.0000000};#define TEST_SIGNAL_SIZE 32double resample(double *signal, int fraction){int i;double total = 0;assert(fraction < 8);for(i = 0; i < 8;i++){total = total + signal * lowpass_fir[i*8+fraction];}return total;}int main(int argc, char *argv[]){int i,j;double test_signal;for(i = 0; i < TEST_SIGNAL_SIZE; i++){test_signal = sin(i*(2*3.141592) / 6.0+0.001);#if 1/* Convert to a square wave */if(test_signal > 0.0) test_signal = 1.0;else if(test_signal < 0.0) test_signal = -1.0;#endif}for(i = 0; i < TEST_SIGNAL_SIZE; i++)printf("in %3i %13.10f\r\n",i, test_signal);for(i = 0; i < TEST_SIGNAL_SIZE - 8; i++) {for(j=0; j < 8; j++) {double r = resample(test_signal+i,7-j);//printf("%2i+%i/8 %12.10f\r\n", i, j, r);printf("%12.10f\r\n", r);}}return 0;}

author: SirNick
author_rank: Frequent Contributor
timestamp: July 08, 2014, 10:02:28 pm
content: OK, I think I'm getting the gist now, but honestly this is just beyond my current understanding. I have no DSP background whatsoever, although I'm really hoping to change that. I have several RU of simple analog processing (compression, bandpass filtering, etc.) that could easily be replaced by a few lowly Cortex M4F, in much less space. (Not to mention, 4-gang audio taper pots are hard to find. And expensive.) The math doesn't seem that complex in theory, I just don't know it yet.

author: hamster_nz
author_rank: Super Contributor
timestamp: July 08, 2014, 11:24:05 pm
content: Quote from: SirNick on July 08, 2014, 10:02:28 pmIt isn't complex at all once you get started - have a look at Chapters 14-16 of "The Scientist and Engineer's Guide to Digital Signal Processing" (in PDF for free athttp://www.dspguide.com/pdfbook.htm).Actually that whole book is truely awesome - from chapter 20:You must select four parameters to design a Chebyshev filter: (1) a high-pass or low-pass response, (2) the cutoff frequency, (3) the percent ripple in the passband, and (4) the number of poles. Just what is a pole? Here are two answers. If you don't like one, maybe the other will help:Answer 1- The Laplace transform and z-transform are mathematical ways of breaking an impulse response into sinusoids and decaying exponentials. This is done by expressing the system's characteristics as one complex polynomial divided by another complex polynomial. The roots of the numerator are called zeros, while the roots of the denominator are called poles. Since poles and zeros can be complex numbers, it is common to say they have a "location" in the complex plane. Elaborate systems have more poles and zeros than simple ones. Recursive filters are designed by first selecting the location of the poles and zeros, and then finding the appropriate recursion coefficients (or analog components). For example, Butterworth filters have poles that lie on a circle in the complex plane, while in a Chebyshev filter they lie on an ellipse. This is the topic of Chapters 32 and 33.Answer 2- Poles are containers filled with magic powder. The more poles in a filter, the better the filter works.Answer 2 works for me!

author: SirNick
author_rank: Frequent Contributor
timestamp: July 08, 2014, 11:53:16 pm
content: Sold! I'll send that to my phone for (actual) bedtime reading.