INTERACT FORUM

Please login or register.

Login with username, password and session length
Advanced search  
Pages: [1]   Go Down

Author Topic: Play Out Speed: Rate Change  (Read 3043 times)

AndrewFG

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3392
Play Out Speed: Rate Change
« on: March 02, 2015, 03:47:32 pm »

Hi Matt,

Apropos this http://yabb.jriver.com/interact/index.php?topic=90659.msg661335#msg661335 -- Can you please let us know how do you plan to do it? Are you just throwing away, or duplicating, samples? Or are you using the regular transcoder engine to recode the stream with a pitch adjustment? This latter approach would certainly be more elegant than the former. It would do proper sample interpolation, and adjust the dither etc. - whereas IMHO the former approach is just plain barbarianism..

Logged
Author of Whitebear Digital Media Renderer Analyser - http://www.whitebear.ch/dmra.htm
Author of Whitebear - http://www.whitebear.ch/mediaserver.htm

Matt

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 42373
  • Shoes gone again!
Re: Play Out Speed: Rate Change
« Reply #1 on: March 02, 2015, 03:50:45 pm »

Hi Matt,

Apropos this http://yabb.jriver.com/interact/index.php?topic=90659.msg661335#msg661335 -- Can you please let us know how do you plan to do it? Are you just throwing away, or duplicating, samples? Or are you using the regular transcoder engine to recode the stream with a pitch adjustment? This latter approach would certainly be more elegant than the former. It would do proper sample interpolation, and adjust the dither etc. - whereas IMHO the former approach is just plain barbarianism..



It's using the Tempo & Pitch DSP.  It's a pretty sophisticated time stretcher / compressor in my opinion.
Logged
Matt Ashland, JRiver Media Center

AndrewFG

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3392
Re: Play Out Speed: Rate Change
« Reply #2 on: March 02, 2015, 04:06:06 pm »

Hmmm. Interesting.

I guess it is straightforward if you are anyway serving transcoded. But if you are streaming in original format will you in fact transcode that too? i.e. Transcode from original flac to adjusted flac (say)?

In which case, how are you planning to provide the adjusted Content-Length in the HTTP headers? Presumably you will provide an estimated Content-Length (new) := Content-Length (old) * (1 + Rate Adjustment). Or ??

And do you have any thoughts about how you will handle Seek() and Pause/Play actions, that probably require you to satisfy a Byte-Range seek from the renderer concerned? IMHO a clean play through from the start of a track is a relatively easy thing to synchronise even with pitch adjustment. But on the other hand, seeks and pause/play will probably throw it all to hell in a hand basket..

Logged
Author of Whitebear Digital Media Renderer Analyser - http://www.whitebear.ch/dmra.htm
Author of Whitebear - http://www.whitebear.ch/mediaserver.htm

Hendrik

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 10935
Re: Play Out Speed: Rate Change
« Reply #3 on: March 02, 2015, 04:39:49 pm »

Its probably only going to work with MC controlled zones, so that MC  adjusts the timing on output.
Logged
~ nevcairiel
~ Author of LAV Filters

Hilton

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1291
Re: Play Out Speed: Rate Change
« Reply #4 on: March 02, 2015, 04:47:14 pm »

I'll be playing with this later today. Thanks for the effort!

Assume you're using server Push with DSP to sync the streams not the renderer DSP?

I like the idea in principle as it's quite elegant if it works as planned. :)
Logged

jmone

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 14463
  • I won! I won!
Re: Play Out Speed: Rate Change
« Reply #5 on: March 02, 2015, 05:05:24 pm »

I'm looking forward to see how it goes as well with long playing items (say a radio stream).  One feature that will still be missing (I think) will be the ability to push the audio out to linked devices from a Video?
Logged
JRiver CEO Elect

Hilton

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1291
Re: Play Out Speed: Rate Change
« Reply #6 on: March 02, 2015, 05:20:01 pm »

I'll be playing with this later today. Thanks for the effort!

Assume you're using server Push with DSP to sync the streams not the renderer DSP?

I like the idea in principle as it's quite elegant if it works as planned. :)

PS if your doing the above, would it not be possible to automate some of this with some of Andrew's previous suggestions and check the latency of the renderer response to stop/play with a short silent stream?
The server could then pick a default sync rate for the DSP and then leave you to tweak it?
I wouldn't invest the time in this though unless we prove the new approach works as well as we hope!

How well has it been working in the development testing?
Logged

jmone

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 14463
  • I won! I won!
Re: Play Out Speed: Rate Change
« Reply #7 on: March 02, 2015, 07:57:50 pm »

My F5 key just broke  ;D
Logged
JRiver CEO Elect

Hilton

  • Regular Member
  • Citizen of the Universe
  • *****
  • Posts: 1291
Re: Play Out Speed: Rate Change
« Reply #8 on: March 03, 2015, 12:22:03 am »

My F5 key just broke  ;D

Must be on its way soon. I guess it's compiling/stress testing overnight? :)


Logged

jmone

  • Administrator
  • Citizen of the Universe
  • *****
  • Posts: 14463
  • I won! I won!
Re: Play Out Speed: Rate Change
« Reply #9 on: March 03, 2015, 12:39:11 am »

I'll be interstate for the next couple of days so it looks like I get to watch everyone else have fun!
Logged
JRiver CEO Elect

AndrewFG

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3392
Re: Play Out Speed: Rate Change
« Reply #10 on: March 03, 2015, 01:31:50 am »

Its probably only going to work with MC controlled zones, so that MC  adjusts the timing on output.

Yes, indeed it would be much easier to do it on the renderer client side than on the server side. Because you can simply apply the DSP to the bit stream going to the DAC. Then you neither need to worry about how to negotiate the transcoding settings on the server, nor worry about some of the server HTTP issues that I have previously mentioned.

Nevertheless I think you may still have problems with Seek and Pause/Play actions causing the sync to break...

Logged
Author of Whitebear Digital Media Renderer Analyser - http://www.whitebear.ch/dmra.htm
Author of Whitebear - http://www.whitebear.ch/mediaserver.htm

mojave

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3732
  • Requires "iTunes or better" so I installed JRiver
Re: Play Out Speed: Rate Change
« Reply #11 on: March 03, 2015, 09:10:06 am »

The cause of drift has been placed on the difference in DAC clocks. I heard of users using the same DAC's on different zones having drift and users with different DAC's having drift.

I haven't heard too many talk about using multiple identical DAC's for the the same zone. This happens with active speakers. I've used Seaton Sound Catalyst speakers with JRiver. Each speaker has an A/D stage, DSP, D/A, and amplification built in. The speakers never drift. Seaton also used JRiver for playback at Rocky Mountain Audio Fest, Axpona, and T.H.E Show last year. There was no drift at any venue. Furthermore, I've used multiple subwoofers with built in DSP and A/D-D/A stages. There wasn't any drift between the subwoofers. Both the Seaton speakers and the subwoofers are considered mulitiple DAC's, yet they didn't have any problem when used on the same zone.

It seems to me the drift is related to multiple zones in JRiver and not multiple DAC's. Perhaps someone else could do some more testing. While I have lots of DAC's, I don't currently have more than one DAC that is identical with another. A good test would be stereo playback with one DAC used for the left channel and one for the right channel.
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5234
  • "Linux Merit Badge" Recipient
Re: Play Out Speed: Rate Change
« Reply #12 on: March 03, 2015, 09:29:23 am »

I haven't heard too many talk about using multiple identical DAC's for the the same zone. This happens with active speakers. I've used Seaton Sound Catalyst speakers with JRiver. Each speaker has an A/D stage, DSP, D/A, and amplification built in. The speakers never drift. Seaton also used JRiver for playback at Rocky Mountain Audio Fest, Axpona, and T.H.E Show last year. There was no drift at any venue. Furthermore, I've used multiple subwoofers with built in DSP and A/D-D/A stages. There wasn't any drift between the subwoofers. Both the Seaton speakers and the subwoofers are considered mulitiple DAC's, yet they didn't have any problem when used on the same zone.

How are these speakers/DACs/subs connected to the computer?  

If they're taking an analog input, and then internally digitizing it, processing, and then sending it through a DAC, it's probably all internally connected via I2S or I2C, which carries the clock along with the PCM on a separate pin. So as long as the analog input is synced, I would expect the outputs will be too.

If the speakers are connected via SPDIF, AES/EBU or ADAT, the transmitted signal is also carrying the clock so I wouldn't expect any drift.  If they're connected via USB or HDMI, I would expect drift as those signals don't carry the clock (but would love to hear about technology that syncs with those types of connections).  

To be clear, I can easily get two DACs to play in sync in JRiver if I feed one an SPDIF signal from the other, but many interfaces lack an SPDIF input, and many more lack an SPDIF output making it hard to daisy chain.  Similarly, many folks have made multichannel interfaces by syncing multiple DAC boards using I2S; if you're handy with a soldering iron, it apparently works great.

The issue (as I see it) is trying to sync two DACs that don't have an obvious way to accept a digital format that carries the clock. In the absence of a clock signal, DACs just seem to empty their buffers in their own time and in their own way.

[Edited for clarity]

It seems to me the drift is related to multiple zones in JRiver and not multiple DAC's. Perhaps someone else could do some more testing. While I have lots of DAC's, I don't currently have more than one DAC that is identical with another. A good test would be stereo playback with one DAC used for the left channel and one for the right channel.

I have a pair of identical USB DACs and am willing to test, but how could you even configure JRiver to address both of them at once in a single zone?  You can only pick one output device.  You'd need external software to link them up and present as one audio device, which would complicate the picture.  If you can think of a test methodology for addressing two dacs in one zone in JRiver, I'll try it and report back.  

I recall at one point trying to use ASIO4All to do what you're describing and it didn't work, but ASIO4All is kind of flaky, so I'm open to testing with a better suggestion.
Logged

mojave

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3732
  • Requires "iTunes or better" so I installed JRiver
Re: Play Out Speed: Rate Change
« Reply #13 on: March 03, 2015, 10:06:48 am »

How are these speakers/DACs/subs connected to the computer?  If they're taking an analog input, digitizing it, processing, and then sending it through a DAC, it's probably all internally connected via I2S, which carries the clock, so as long as the analog input is synced, I would expect the outputs will be too.
They are connected to a preamp/processor, receiver, or audio device via analog balanced output (XLR). So since the analog signal is synced to each speaker, the DAC's then stay in sync through the entire process? The speakers or subwoofers themselves aren't linked in any way.

Quote
I have a pair of identical USB DACs and am willing to test, but how could you even configure JRiver to address both of them at once in a single zone?  You can only pick one output device.  You'd need external software to link them up and present as one audio device, which would complicate the picture.  If you can think of a test methodology for addressing two dacs in one zone in JRiver, I'll try it and report back.  

I recall at one point trying to use ASIO4All to do what you're describing and it didn't work, but ASIO4All is kind of flaky, so I'm open to testing with a better suggestion.
I guess I was thinking of using analog input into the an A/D-D/A like my Tascam US-366. Another way would be to use digital output using a Lynx AES16e card (which I have) or an SPDIF splitter.

I just remembered that I have used digital output from my AES16e to two different DAC's. They stayed completely in sync. I used one for the left channel and the other for the right channel in my testing. In this case the AES16e is the master clock sending it out via AES to the DAC's. Even though the DAC's were different, no drift occurred.

If I was doing whole house audio, I would probably just get a Motu 24ao for under $1000 and run balanced cables to all the rooms.
Logged

mwillems

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 5234
  • "Linux Merit Badge" Recipient
Re: Play Out Speed: Rate Change
« Reply #14 on: March 03, 2015, 10:31:48 am »

They are connected to a preamp/processor, receiver, or audio device via analog balanced output (XLR). So since the analog signal is synced to each speaker, the DAC's then stay in sync through the entire process? The speakers or subwoofers themselves aren't linked in any way.

I expect that the ADC's are successfully recovering the clock and sending it via I2S or I2C to the DACs, which keeps them in sync.  If the clock recovery is good and the clock signal is transmitted, they wouldn't need to be interconnected as the analog input would be effectively controlling the rate of playback. 

Quote

I guess I was thinking of using analog input into the an A/D-D/A like my Tascam US-366. Another way would be to use digital output using a Lynx AES16e card (which I have) or an SPDIF splitter.

I just remembered that I have used digital output from my AES16e to two different DAC's. They stayed completely in sync. I used one for the left channel and the other for the right channel in my testing. In this case the AES16e is the master clock sending it out via AES to the DAC's. Even though the DAC's were different, no drift occurred.

It's because you're sending the clock, and the devices support receiving a clock.  If devices can be connected in a way that transmits a clock, it will work.  I had an M-Audio PCI card with an analog output and an SPDIF output.  I hooked up the SPDIF output to the SPDIF input on another DAC, and sent four channel output to the M-audio card in JRiver.  The M-Audio card and the external DAC stayed in perfect sync (good enough for an active crossover). 

The hard part is how to sync two dacs that only have USB inputs, or two receivers that only have HDMI inputs, or two DLNA renderers that have no physical inputs at all.  I'm not saying those things are impossible, just that I've personally had no success with them.  If all devices had SPDIF inputs, we could all just use SPDIF splitters and call it a day  ;D

Quote
If I was doing whole house audio, I would probably just get a Motu 24ao for under $1000 and run balanced cables to all the rooms.

My long-term plan is to buy a second Steinberg 824 and use ADAT to sync them.
Logged

AndrewFG

  • MC Beta Team
  • Citizen of the Universe
  • *****
  • Posts: 3392
Re: Play Out Speed: Rate Change
« Reply #15 on: March 03, 2015, 03:31:12 pm »

Dear Matt,

You might consider the WASPI code that I posted in my white paper "Synchronised Audio Playback in MC" on the beta board...

Logged
Author of Whitebear Digital Media Renderer Analyser - http://www.whitebear.ch/dmra.htm
Author of Whitebear - http://www.whitebear.ch/mediaserver.htm
Pages: [1]   Go Up