How do I transfer a sound file via TCP?

[smercurio_fc]

Of course it matters. TCP/IP isn't the same as GPIB. If you're telling it to read 8 bytes and there's only 4 bytes the TCP/IP Read will sit there waiting for the rest that you told it to read. In your case for the first part you were reading the 4 bytes which corresponded to the number that was the number of bytes plus the first 4 bytes of the data which got sent right after it, and trying to convert the 8 bytes to an I32 which is only 4 bytes. Result: junk.

[MSAT]

Ok so im getting sound out of both ends but the client side is faster than the server side.  What do I need to do in order to slow the transfer?  Or is it something with my sampling rate?  Its set at the same sampling rate as it is on the server side.  Should it be different client side?

[smercurio_fc]

At ths point you should rethink your strategy and implementaion. All music streaming works by buffering data. You have no buffering mechanism in place. You are assuming perfect synchronization between the server and the client. This will never happen, even if the computers are connected directly together with a crossover cable. Buffering basically involves having the client wait until a certain amount of data is available before it starts playing. Thus, if the server blips out momentarily, the client can still keep playing. The amount of data is really up to you. It can be seconds or minutes. The sampling rate will tell you how many elements you will need.

[MSAT]

I understand what youre saying it will just take me a second to actually learn how to do it in LV.  The dt value being sent over is constant so this shouldnt have to be written to a buffer should it?  Just the Y values right?

I searched through the example finder and saw the smart buffer.vi.  Would this be a good vi to use in this type of application?

[MarkBlack]

You could use this example, but it might be easier to impliment using a Producer/Consumer architecture.  This would allow you to use the Get Queue status.vi to determine whether your buffer (queue) is large enough to begin playback. 

Let me know if you are unfamilar with this architecture.

Message Edited by BLAQmx on 03-28-2008 10:26 AM

[MSAT]

The queue vi's worked out quite well.  All I had to do was have the Y data going into a timed sequence structure that would place the values into a queue, wait for a second, and then push them out of the queue into the build array and then output by the sound.  It took me a second to find out how long to hold the values in the queue but I just used a control and listened for the correct amount of time.  But it sounded fine once I got the timing down.  Weird thing is...every now and again I can hear other parts of the track while its playing.  like it will skip to another part and then get back on track..is it because of the delay in receiving the transferred data that's causing this?

[smercurio_fc]

Do you have one or two loops in your client? The producer-consumer architecture is based on 2 loops. One loop simply acts to receive data and dump it into a queue. It does nothing else. The other loop simply looks at the queue to determine if there's enough there to begin playing, and if so it just gets the data to play by getting the values from the queue.

[smercurio_fc]

Two minor "oh by the way"s...

• You could eliminate one of the TCP Writes and Reads by not preceding the transmission of dt with the size. You only need to do that if you don't know at the receiving end how many bytes you're going to get, and you want to establish a protocol that says the first thing to read is a 32-bit integer that will tell you how many bytes follow. However, the number of bytes for dt is always the same - it's a DBL. So, sending the size of a DBL is somewhat superfluous in this case. Technically, it could change in the future, though, so leaving it in there isn't going to cause any harm.
• At the client side you're not specifying the configuration of the sound card. The default uses 22kHz, and I believe the sound you're trying to play is a 44kHz sound.
  

[MSAT]

Yeah I noticed that about the sampling rate so I changed it when I first thought my design was faulty and once I put in 44100 Hz it started working fine except for one part.  At one part in the track the music speeds up and then I get that old error "memory full".  I'm wondering if it's because of the bitrate of the track itself.  If the track was compressed at a variable bitrate would sections that surpass the sampling rate of the VI end up causing this error.  Because it's only at that part in the track when the music speeds up that the VI fails.  All the music leading up to it is fine except for a small, but noticeable delay, between server and client.  But once it hits that point, the client fails and stops and the server actually speeds up.  Should I alter my sampling rate client-side to compensate for this?

[smercurio_fc]

Unfortunately, I don't know the answer to this question.