Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[6233638]

OK, I did some further latency testing.
As stated on the TuneBlade website, the minimum buffer size that works with the original AirPort Express v1 devices is 350ms.
I expected that it just wouldn't be stable below that, but it doesn't play audio at all.
So the range that you can use with this hardware is 350-3000ms.

And as posted here, it turns out that most people think that something has gone wrong when you have 3 seconds of latency and hit the play/pause/skip button again because it's taking so long.
From the testing that I have done, I don't seem to be running into any problems using the minimum 350ms buffer size for that hardware with TuneBlade.
I'd need to do more testing that to see if it is stable over longer periods of time, but it seems to be fine.
 
However I was wrong in my assumption that the "play silence for hardware synchronization" would have to be matched to the TuneBlade buffer size when using standby.
It turns out that it needs to be set to 3 seconds with AirPort Express v1 hardware regardless of the buffer size.
 
But the reduced buffer size still means that seeking, volume adjustments, or other playback controls are far more responsive than they were before. It just takes 3.35 seconds whenever you start playback before you hear anything.

[bspachman]

Thanks so much for the pointers! I did have this all working at one point yesterday, but in my quest for simplification, lost it. Now it's back! The only portion of your tips I was unable to figure out was how to force the sampling to 44.1/16. I saw in DSP studio that you can force the sample rate, but I couldn’t find the bit depth setting….

In all my messing around, I did come up with some instabilities--Airfoil Speakers doesn't like it when you change the default Windows audio device, and neither does TuneBlade. Speakers would often crash and TuneBlade would hang at various points as I attempted to force the audio to travel the path I sought. Hopefully these little quirks will be less obvious as I settle into operating instead of constantly re-configuring.

I was hoping to eliminate the need to run Airfoil Speakers as an Airplay destination on the server. But it seems to be an added bit of complexity that is needed in order to keep the server (connected to my main playback system) in sync with all the other Airplay destinations.

I wonder if there’s a way to have my multi-channel/high-resolution music play in its full “bit-perfect” surround/high-resolution-ness on the server with that signal being sent to my receiver, while simultaneously having the same music sent to the Airplay destinations.

Regardless, some good steps made. Right now, all video files are played back in my “Local” zone. All audio files are played back in my “TuneBlade” zone, which sends to all my Airplay devices, including Airfoil Speakers on the server in order to keep everything in sync. MC’s “TuneBlade” zone is set to resample all audio to 44.1 and 2channel, so all of my oddball multi-channel and high-resoluton files play back well. NOTE: it was important to have the TuneBlade zone set to NO BITSTREAMING, or several of my filetypes would not play (AC3, DTS, and so forth). Does the bitstreaming setting bypass MC’s DSP studio?

A buffer of 250ms seems to work great in TuneBlade, and I haven’t found the need to adjust the silence for hardware sync setting. I don’t have any AirPort Expresses that are that old :-)

However, software Airplay destinations (Airfoil Speakers on Windows & Mac) frequently do not pick up the stream from TuneBlade, despite TuneBlade showing they are connected. A toggle of the connection status normally revives the connection. Increasing the TuneBlade buffer doesn’t seem to help resolve this problem. Adjusting the silence for hardware sync setting doesn’t seem to help either. I don’t notice the issue on my hardware destinations. Anyone else seeing this on their software destinations?

I’d love to figure out a way to have the TuneBlade control not minimize to the system tray—especially when doing so much monkeying around with configurations!

Definitely $10 well-spent!

brad

[6233638]

Thanks so much for the pointers! I did have this all working at one point yesterday, but in my quest for simplification, lost it. Now it's back!
The only portion of your tips I was unable to figure out was how to force the sampling to 44.1/16. I saw in DSP studio that you can force the sample rate, but I couldn’t find the bit depth setting….

Great!

Bit-depth is set in the device properties. (Tools → Options → Audio → Audio Device → Device Settings)

(don't use 10ms here, it just happened to be that when I took a screenshot)

And in case it stumps anyone else, sample rate and number of channels are set in the DSP Studio. (Tools → Options → Audio → Settings → DSP Studio)


Just right-click the sample rate box and set all to 44,100 Hz.

In all my messing around, I did come up with some instabilities--Airfoil Speakers doesn't like it when you change the default Windows audio device, and neither does TuneBlade. Speakers would often crash and TuneBlade would hang at various points as I attempted to force the audio to travel the path I sought. Hopefully these little quirks will be less obvious as I settle into operating instead of constantly re-configuring.

Are you up to date with Airfoil Speakers? It has been stable here.
TuneBlade too, for that matter.

And you say that you're changing the default audio device. Do you mean when TuneBlade sets the default device, as specified in this step, or that you are changing it after that?

For what it's worth, I have not had that issue at all, and I often switch between three local devices on my PC. (unrelated to AirPlay)
I could see Direct Loopback perhaps not handling those changes well, but I'm not sure why that would affect Airfoil Speakers.
Perhaps if something has Exclusive Access to the device that Airfoil Speakers is trying to play to, it handles that badly.

I was hoping to eliminate the need to run Airfoil Speakers as an Airplay destination on the server. But it seems to be an added bit of complexity that is needed in order to keep the server (connected to my main playback system) in sync with all the other Airplay destinations.

Airfoil Speakers will be required to keep everything in perfect sync, since it will adjust itself to stay in sync as it drifts over time. (and sync will drift over time)

I wonder if there’s a way to have my multi-channel/high-resolution music play in its full “bit-perfect” surround/high-resolution-ness on the server with that signal being sent to my receiver, while simultaneously having the same music sent to the Airplay destinations.

Not if you want it in sync, nor if you want the highest quality possible sent to the AirPlay receivers.

If absolutely perfect sync is not required, you could try using Linked Zones in Media Center to do this while staying mostly in sync.
I just set up a test where I linked my AirPlay Zone (16/44) to my Headphones Zone (max 24/192) and after adding an 860ms delay by having the headphones on one ear and speakers in the room playing via airplay then spending a minute to find the right value, both of them were playing in more-or-less perfect sync, while the headphone zone was playing a 24/96 track and AirPlay received a 16/44 version of the same track.
 
The issue that I ran into was when the sample rate changed. My DAC takes a fraction of a second to switch over to the new rate, and this was enough to throw things out of sync again.
Pausing and resuming, since that did not have to change the DAC's sample rate again, brought them back into sync.
What might be an acceptable solution would be to resample everything to the highest rate that your DAC supports. That way you're still getting high res audio, but (hopefully) avoid breaking sync when the sample rate changes.
 
I do expect that it will likely drift over time though, so it may or may not be a suitable solution.

NOTE: it was important to have the TuneBlade zone set to NO BITSTREAMING, or several of my filetypes would not play (AC3, DTS, and so forth). Does the bitstreaming setting bypass MC’s DSP studio?

Yes, that's exactly what bitstreaming does.

However, software Airplay destinations (Airfoil Speakers on Windows & Mac) frequently do not pick up the stream from TuneBlade, despite TuneBlade showing they are connected. A toggle of the connection status normally revives the connection. Increasing the TuneBlade buffer doesn’t seem to help resolve this problem. Adjusting the silence for hardware sync setting doesn’t seem to help either. I don’t notice the issue on my hardware destinations. Anyone else seeing this on their software destinations?

It may be the 250ms buffer causing this. Perhaps it's too short for them?
I did see similar behavior from Airfoil Speakers initially as well, but it hasn't been a problem for me the last couple of days.
Edit: After doing more testing, the connection to Airfoil Speakers does seem quite unreliable. I've mostly been playing to Apple hardware so it had not tested it much.
What I'd found is that hitting stop on the Airfoil Speakers app to kill the connection means that it works again 100% of the time, the next time I connect to it.
I've contacted Rogue Amoeba support about this, so I'll see where it goes.

[bspachman]

Are you up to date with Airfoil Speakers? It has been stable here.
TuneBlade too, for that matter.

And you say that you're changing the default audio device. Do you mean when TuneBlade sets the default device, as specified in this step, or that you are changing it after that?

For what it's worth, I have not had that issue at all, and I often switch between three local devices on my PC. (unrelated to AirPlay)
I could see Direct Loopback perhaps not handling those changes well, but I'm not sure why that would affect Airfoil Speakers.

The instability was manifesting when I was focusing on "Direct Loopback" as TuneBlade's audio capture method, so I was using the Windows sound control panel to change my default device quite a bit. I'm not surprised that messing around at the bottom of the audio stack would cause issues, but it was driving me nuts yesterday!

Perhaps if something has Exclusive Access to the device that Airfoil Speakers is trying to play to, it handles that badly.
Airfoil Speakers will be required to keep everything in perfect sync, since it will adjust itself to stay in sync as it drifts over time. (and sync will drift over time)
Not if you want it in sync, nor if you want the highest quality possible sent to the AirPlay receivers.

I think you've nailed it here. While testing my zone switching setup today, Airfoil Speakers also kept crashing. I finally realized it was unhappy when it was connected (via TuneBlade) AND when I used MC to send audio to the local PC output--the same output that Airfoil Speakers sends to. Since MC is set up for exclusive access the the audio device, I'm guessing that AFS doesn't like being kicked off I'll be opening a ticket with Rogue Amoeba to see if there's anything they can do--even if it's to fail more gracefully.

Regardless, if TuneBlade has disconnected (either manually or through its standby timeout), then everything works fine. I'll play around with shortening the timeout delay, and maybe I'll get into alternate dithering methods as you suggested earlier.

If absolutely perfect sync is not required, you could try using Linked Zones in Media Center to do this while staying mostly in sync.

Yep. I remembered that feature today too and in my tests found much the same (780ms delay). It looks like a bug in MC that the delay did not stay applied when stopping/re-starting playback. Did you see evidence of that behavior? MC retained the setting, but didn't seem to apply it properly.

For now, I'll stick with using Airfoil speakers on the server to keep the local audio in sync with the remote audio. It seems the least brittle of the various solutions at this point. I'll have to track to see if I get any improvement in standby/re-connection behavior.

Thanks!
brad

[Hilton]

I'll post a more detailed response later but I've solved all the Airfoil,  MC & TuneBlade conflicts so they never crash. I can switch between spotify, MC on the server remotely. There's not much to it really.
Use a dedicated output device on the server for TuneBlade that isn't used by anything else. Install a virtual one if you don't have one spare.
Set TuneBlade to that specific device instead of using loop back.
Set the device windows control panel audio settings to 16/44 on the server and as the default playback device.
Set airfoil speakers on the server to your default sound card (the same as TuneBlade)
Make sure exclusive mode is turned off everywhere on the server relating to the TuneBlade Audio device that your using.

On the receivers, set Airfoil Speakers to use default device. Set Windows control panel Audio device that you prefer to use as your default device. Turn off exclusive mode in MC if your also using that output device for MC.
It sounds like a lot of fiddling but it's only a couple changes. When I'm not on my phone I'll try simplify this with some pics.

I can now start spotify on the server, send that via TuneBlade automatically, switch to MC and start playback, the worst that will happen is sound overlapping from both. Which is easier to fix than going to your of to restart things.

I'm using the spotify beta which now allows remote control of spotify on the server from any other PC from the new Beta. Phones can also remotely control spotify, so with spotify, JRemote and TuneBlade remote I can do everything I need to do from the phone without having to go near a PC or touch my MC server.

[6233638]

Well that is essentially the same as this, only you're disabling Exclusive Access.
And if you're having conflicts/crashes, that may be the solution.

[Hilton]

Actually it's similar but it's still different. Thanks for helping though! Yes turning off exclusive access is one thing but the device also needs to be set to 16/44 as well as in the MC AirPlay zone so that every thing is sent in the same format.