In Reply to: I am a bit surprised and confused..... posted by Cut-Throat on August 6, 2012 at 12:57:40:
Ok. All this is getting Off TOPIC.
But let's finish this.
Obviously you have followed the endless discussions about that topic in
other parts of the virtual landscape.
If you do the pcm conversion on the server, it's a fact that all files formats are sent as PCM data towards the client.
The "pull the cable" test is IMO too short and might cause weired error conditions and from my experience won't lead anywhere.
Run the tests I told you. Otherwise you'd be shifting conditions too much.
The Touch network buffer is a "streaming" FIFO buffer. Data is not copied in there in large data chunks. (Note: The actual audio buffer towards the audio interface is a different animal!! - size is usually a couple of ms)
That means there's a continous buffer management and continous interaction with the NIC (network interface card) ongoing. Somebody has to control all that. (I'm pretty sure that doing bulk copies of large data chunks instead of streaming could improve the situation)
The NIC meets the stream prior to that buffer. It has
continously to work with the stream on a packet basis. It's a pretty tough job the NIC has to do.
You can easily test this, if you assign quite low priorities to the NIC associated interrupts. What you'll experience are "immediate" XRUNS on the audio interface, even with a buffer filled of 20s of data!!!
That tells us that the processor considers the buffer as a seperate element.
That's why IMO the huge buffer (20-30s) plays a minor role in the game.
Now. Let's assume that slightest variations on load, noise spectrum (most people just talk about noise - but noise is a complex continously changing spectrum of everything) inside a computer - at almost any position (you'll find over here at AA that even SATA cable make a difference) - can have a certain impact on the audio interface. My guess would be that varying load conditions on e.g. a NIC, might have also some impact. (As I said earlier - my interrupt test has shown that there is a much more direct relationship to the whole, than the 30s buffer size would suggest) )
Obviously above also implies that there are certain changing conditions/variations seen on the network side. It's probably
similar to asynchronous DACs. What I mean here is, that if you (as the receiving end) ask for a packet it doesn't mean that you'll get it always in exactly the same time frame and packaging.
But again. Run the different files and make up your own mind. To test
this takes you less time then me writing this post... ...about things and speculations nobody is able to prove anyhow.
This post is made possible by the generous support of people like you and our sponsors:
Topic - automatic tagging after tracks have been ripped (linux) - bullethead 20:43:17 08/04/12 (14)
- RE: automatic tagging after tracks have been ripped (linux) - J.Mac 21:19:49 08/04/12 (13)
- thanks - bullethead 08:58:03 08/05/12 (12)
- RE: thanks - soundchekk 00:58:47 08/06/12 (11)
- Question - Cut-Throat 05:56:15 08/06/12 (10)
- RE: Question - soundchekk 06:07:41 08/06/12 (9)
- Yes, I have applied your Toolbox already........... - Cut-Throat 06:13:22 08/06/12 (8)
- RE: Yes, I have applied your Toolbox already........... - soundchekk 06:44:13 08/06/12 (7)
- I am a bit surprised and confused..... - Cut-Throat 12:57:40 08/06/12 (6)
- RE: I am a bit surprised and confused..... - Tony Lauck 08:02:06 08/07/12 (1)
- RE: I am a bit surprised and confused..... - Cut-Throat 09:49:15 08/07/12 (0)
- RE: I am a bit surprised and confused..... - soundchekk 23:12:52 08/06/12 (3)Follow Ups
- RE: I am a bit surprised and confused..... - soundchekk 23:12:52 08/06/12 (3)