Internet music streaming and sample clocks: how does it work? - diyAudio
Go Back   Home > Forums > Source & Line > PC Based

PC Based Computer music servers, crossovers, and equalization

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 15th April 2012, 08:34 AM   #1
diyAudio Member
 
Join Date: Feb 2009
Location: UK
Default Internet music streaming and sample clocks: how does it work?

You might simply assume that it is the sound card that provides the sample clock when listening to music on your PC. I can see how this would work if the music data can be delivered 'on demand' in chunks at the average rate the sound card requires. Is this how it works when listening to personal music streams e.g. Spotify?

But what about internet music broadcasting e.g. internet radio, or live TV streaming? How is the discrepancy between your sound card's sample clock and the broadcast's sample rate resolved?

And there's a further technicality I'm curious about: some sound cards e.g. Creative Audigy, work at a fixed sample rate (48kHz) and supposedly re-sample everything to their own internal clock rate. I can picture this for, say, the SPDIF input, but how does it work for listening to 44.1kHz music off the hard drive? Does the PC provide a 44.1kHz (but surely jittery?) stream to the card, which it then re-samples to 48 kHz? Or does the card demand chunks of data from the PC at an average 44.1kHz sample rate and do the re-sampling purely in soft (firm-)ware? Or does something clever happen in the driver?

Thanks for any thoughts on this.
  Reply With Quote
Old 15th April 2012, 01:26 PM   #2
diyAudio Member
 
Join Date: Jan 2008
Location: Virginia
1. You have seen the word "buffering" on those stations?
The data comes when it comes, is stored in a big memory buffer and read with the audio clock is the one provided by PC. If they get too much out of wack due to low bandwidth, you will hear pauses and wait for buffering.
The same buffering can be used anywhere in the audio chain to isolate the clocks. It is a project here that does that for SPDIF transmission. There are CD/DVD players that use the buffering and dedicated audio DSP for the same purpose.
2. All the soundcards can work with any samplerate because they have a programmable frequency divider inside. Driver choses the right divider based on the Windows mixer "instructions". Not very clean, but works. Memory buffer is used inside Windows mixer to account for differences (and that 'mixer" is a quality issue sometimes, bypassed by ASIO drivers). Jitter from that divider of course is an issue.
Creative soundcards are a special case. They also can work with any samplerate, the difference is that they have an on-board DSP that does the samplerate conversion (ASRC). The second generation also have a bit-perfect mode that bypasses that DSP with a DMA (but you loose other effects). X-Fi has a monster DSP for that ASRC conversion. E-MU cards, like all the "pro" soundcards, have solved the problem with two different clocks (that have to be selected manually, per incoming stream).

Last edited by SoNic_real_one; 15th April 2012 at 01:48 PM.
  Reply With Quote
Old 15th April 2012, 08:25 PM   #3
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by CopperTop View Post

But what about internet music broadcasting e.g. internet radio, or live TV streaming? How is the discrepancy between your sound card's sample clock and the broadcast's sample rate resolved?
This is a very good question. An interesting explanation of options can be found at http://www.icg.isy.liu.se/courses/ts...altime-4up.pdf . Basically either drop/interpolate samples to keep the input buffer optimally filled, or adaptively resample the stream using the incoming timing information in the stream. It is not a simple task at all. I have not been able to locate the place in mplayer source code where some form of synchronization occurs.
  Reply With Quote
Old 18th April 2012, 10:47 AM   #4
diyAudio Member
 
Join Date: Jan 2008
Location: Virginia
Because there is no "interpolation" or "resampling". You loose the stream, you loose the data, that's why is used a buffer, to allow for retries. That buffering protocol is not in the player, is in the network driver.
  Reply With Quote
Old 18th April 2012, 10:55 AM   #5
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by SoNic_real_one View Post
Because there is no "interpolation" or "resampling". You loose the stream, you loose the data, that's why is used a buffer, to allow for retries. That buffering protocol is not in the player, is in the network driver.
Yes, when referring to network latency/unreliability, there is the buffer. But you have to account for long-term bitrate difference of incoming and outgoing streams - timing in the transmitter, how fast it is sending data and timing in the sound card clock. If the transmitter is slower, you can always break the playback and wait a bit for refilling the buffer. If the transmitter is faster, you end up with full buffer and have to decide what to do with superfluous samples - either dropping, or adaptively resampling. Simple solutions use the dropping/sample interpolation (mplayer? I do not know), more sophisticated (such as network pulseaudio or jackd streaming) use continous adaptive resampling via libsamplerate to bridge the average incoming and outgoing clocks.
  Reply With Quote
Old 25th April 2012, 07:19 AM   #6
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Here is a new presentation on adaptive resampling by Fons Adriaensen, developer of jack network layer and many other useful audio tools: LAC 2012: Linux Audio Conference
  Reply With Quote
Old 11th June 2012, 12:45 AM   #7
nowhere is offline nowhere  Israel
diyAudio Member
 
Join Date: Jun 2012
Quote:
Originally Posted by SoNic_real_one View Post
Because there is no "interpolation" or "resampling". You loose the stream, you loose the data, that's why is used a buffer, to allow for retries. That buffering protocol is not in the player, is in the network driver.
Buffer doesn't help in this case.

For example, if input stream has exactly 44100 samples per second, and the soundcard has clock frequency of 44090 samples per second, there will be an overrun of 10 samples per second - regardless of any "games" with buffers.

So, some kind of interpolation is necessary.

Look, for example, for 'jack_diplomat' in Sound Engineers Guide To Jack .
  Reply With Quote
Old 26th June 2012, 06:14 AM   #8
cnt is offline cnt  United States
diyAudio Member
 
Join Date: Jun 2012
Location: Seattle, WA
Quote:
Originally Posted by nowhere View Post
Buffer doesn't help in this case.

For example, if input stream has exactly 44100 samples per second, and the soundcard has clock frequency of 44090 samples per second, there will be an overrun of 10 samples per second - regardless of any "games" with buffers.

So, some kind of interpolation is necessary.

Look, for example, for 'jack_diplomat' in Sound Engineers Guide To Jack .
continuing that math, if you buffered one second before starting (or just send the previous seconds worth of music all at once), and the sample rates were as above it would take you 3 days before you hit an empty buffer, at which point the player stutters for a second and goes on for another three days.
  Reply With Quote
Old 26th June 2012, 07:14 AM   #9
phofman is offline phofman  Czech Republic
diyAudio Member
 
Join Date: Apr 2005
Location: Pilsen
Quote:
Originally Posted by cnt View Post
continuing that math, if you buffered one second before starting (or just send the previous seconds worth of music all at once), and the sample rates were as above it would take you 3 days before you hit an empty buffer, at which point the player stutters for a second and goes on for another three days.
Yes, that is why simple stream players just drop or duplicate samples to keep the buffer filled. However, it is a compromise between quality/performance and complexity/CPU demands. E.g. jackd or pulseaudio do not accept this compromise and do proper adaptive resampling.
  Reply With Quote
Old 26th June 2012, 06:19 PM   #10
cnt is offline cnt  United States
diyAudio Member
 
Join Date: Jun 2012
Location: Seattle, WA
I guess my point was that i doubt many audio players do any kind of resampling and rather just accept that occasionally your buffer may under run. I have no doubt that other coding schemes are better if that is not acceptable.

Interestingly I was curious how bad just doubling 10 samples every second at 44100samp/sec would be. I worked an example of a 3khz sin wave. Here's the picture in the frequency domain. So the strongest peak from distortion is about -23db.

Click the image to open in full size.
  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
What happened to music after THE INTERNET! Quenepas Music 19 12th January 2012 10:51 PM
HD radio vs Internet streaming jfitz57 Digital Source 8 7th September 2011 12:06 AM
A tube-preamp with DSP-DAC-Touchscreen-and Music Streaming... rha1211 Tubes / Valves 4 5th August 2011 11:31 PM
LAN Switch upgrade to Internet streaming hillbear PC Based 0 10th September 2010 03:50 PM
Combined DAB, Internet Radio, Streaming module sonnya Digital Source 0 22nd October 2009 06:51 AM


New To Site? Need Help?

All times are GMT. The time now is 04:39 AM.


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