PDA

View Full Version : Squeezebox replacement with Andoid Mini PC + DAC, e.g. A10, RK3066



xvlun
2013-05-20, 04:45
it seems there already are quite a few projects on the way to help compensate for the lack of squeezebox compatible hardware since logitech decided to cancel the product line, but either the replacement hardware is scarce and hard to come by (pogoplug) or the price seems to be quite on the high side (wandboard). This makes me wonder if there is a way to make cheaper systems for people how care more about multiroom sync than high end audio. Maybe based on android arm platforms like the Allwinner A10 or Rockchip RK3066 in combination with external dacs (e.g. chinese muse pcm2704 based), which seem to be much cheaper.

So far I have two squeezelite clients on x86 hardware which are connected to the network via ethernet and which will play synced music for hours without experiencing any skip ahead events. When I add the raspberry pi connected via lan, skip ahead events on the pi occur every 10-15 seconds amounting to 10-15 msec while the two others stay in sync. Unfortunately this is not the case when adding another client (raspberry pi, A10 Tablet, Motorola Defy) via wifi, which I ascribe to wifi latency issues (caused by ~20 wifis around here). But also if i increase the minimum sync difference, the wifi clients will slowly run out of sync (faster in case of the raspberry, which i think might be caused by the usb issues).

Now my question would be: given an ideal wired network and using an android mini pc equipped with an external usb dac, who is in charge of the timing? will this be determined by the pc or the dac? So does it matter if I buy a RK3066 based device like the MK808 or an MK802 which is A10 based? Will it depend on the specific clock the company puts on the pcb? or is it all contriolled by the usb dac?

bpa
2013-05-20, 05:03
Sync depends on the player h/w having an accurate RTC clock. LMS makes sync decisions based on the clock values return by player.

Have you tried adjusting the sync params for the player in the LMS Settings/Player/Synchronize page and also looking at the LMS log to see why LMS is making adjustments (e.g. to determine main issue such as network latency or bad RTC clock).

pippin
2013-05-20, 10:59
But the biggest impact on timing is actually in the driver, isn't it? If it dynamically buffers and you get an unpredictable delay between queuing up samples and the time they are actually being played, you've got no chance to stay in sync while a driver with a small internal buffer playing out immediately will give you a much better behavior.

As I understand bluegaspode, there's a pretty wide variety between implementations on different Android devices so there's probably no way to answer the question on the basis of "some Android PC"

xvlun
2013-05-20, 11:44
Sync depends on the player h/w having an accurate RTC clock. LMS makes sync decisions based on the clock values return by player.

but which one? the one integrated into the mk808? or the one on the pcb of the external usb dac?


Have you tried adjusting the sync params for the player in the LMS Settings/Player/Synchronize page and also looking at the LMS log to see why LMS is making adjustments (e.g. to determine main issue such as network latency or bad RTC clock).
yes. i have made a click track using audacity which consits of 1msec clicks every two seconds. based on that its relatively easy to hear differences, which i of course corrected using the player menus in lms. haven't found anything in server.log regarding the skip aheads though...

xvlun
2013-05-20, 11:46
As I understand bluegaspode, there's a pretty wide variety between implementations on different Android devices so there's probably no way to answer the question on the basis of "some Android PC"

my question rather is, which part of the android pc (e.g. mk808) + dac (muse)combination is responsible, as both must have their own real time clocks.

pippin
2013-05-20, 12:14
And my answer is: it depends on the driver, not on the hardware. If the driver is able to sync the output on the DAC side, it will work.
Me are not talking about synchronization in microsecond levels, the maximum allowed delay is 10ms and as soon as the delay is constant, it can be even much longer.

In the end the player software does the synchronization and that runs on the main CPU.

bpa
2013-05-20, 14:27
haven't found anything in server.log regarding the skip aheads though...

Did you enable player.sync to DEBUG ?

xvlun
2013-05-30, 11:32
Have you tried adjusting the sync params for the player in the LMS Settings/Player/Synchronize page and also looking at the LMS log to see why LMS is making adjustments (e.g. to determine main issue such as network latency or bad RTC clock).

i have had a look at the server.log, the raspberry seems to be a little ahead after sync, but loses time quite fast. I dont unterstand the "adjust jiffies" part, does this mean the raspberries clock is adjusted?


[13-05-28 21:53:17.0128] Slim::Player::StreamingController::_CheckSync (559) b8:27:eb:ad:a7:7b resync: skipAhead 12ms
[13-05-28 21:53:19.0259] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.954, 00:24:1d:89:06:20: +0
[13-05-28 21:53:20.0292] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.956, 00:24:1d:89:06:20: +2
[13-05-28 21:53:21.0075] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.955, 00:24:1d:89:06:20: +0
[13-05-28 21:53:22.0103] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.962, 00:24:1d:89:06:20: -3
[13-05-28 21:53:23.0142] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.960, 00:24:1d:89:06:20: -6
[13-05-28 21:53:24.0171] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.959, 00:24:1d:89:06:20: +0
[13-05-28 21:53:25.0074] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.962, 00:24:1d:89:06:20: -3
[13-05-28 21:53:26.0103] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.961, 00:24:1d:89:06:20: -1
[13-05-28 21:53:27.0132] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.963, 00:24:1d:89:06:20: -3
[13-05-28 21:53:28.0165] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.964, 00:24:1d:89:06:20: -4
[13-05-28 21:53:29.0071] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.963, 00:24:1d:89:06:20: -8
[13-05-28 21:53:30.0100] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.966, 00:24:1d:89:06:20: -6
[13-05-28 21:53:31.0043] Slim::Player::Player::trackJiffiesEpoch (981) 00:24:1d:89:06:20 adjust jiffies epoch +0.002s
[13-05-28 21:53:31.0132] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.967, 00:24:1d:89:06:20: -10
[13-05-28 21:53:31.0141] Slim::Player::StreamingController::_CheckSync (559) b8:27:eb:ad:a7:7b resync: skipAhead 10ms
[13-05-28 21:53:33.0075] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.959, 00:24:1d:89:06:20: +2
[13-05-28 21:53:34.0105] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.958, 00:24:1d:89:06:20: +4
[13-05-28 21:53:35.0135] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.961, 00:24:1d:89:06:20: +0
[13-05-28 21:53:36.0165] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.962, 00:24:1d:89:06:20: +0
[13-05-28 21:53:37.0075] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.963, 00:24:1d:89:06:20: -5
[13-05-28 21:53:38.0105] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.964, 00:24:1d:89:06:20: -2
[13-05-28 21:53:39.0133] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.965, 00:24:1d:89:06:20: -8
[13-05-28 21:53:40.0158] Slim::Player::Player::trackJiffiesEpoch (981) b8:27:eb:ad:a7:7b adjust jiffies epoch +0.009s
[13-05-28 21:53:40.0171] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.973, 00:24:1d:89:06:20: -10
[13-05-28 21:53:40.0180] Slim::Player::StreamingController::_CheckSync (559) b8:27:eb:ad:a7:7b resync: skipAhead 10ms
[13-05-28 21:53:41.0020] Slim::Player::Player::trackJiffiesEpoch (981) 00:24:1d:89:06:20 adjust jiffies epoch +0.004s
[13-05-28 21:53:42.0104] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.964, 00:24:1d:89:06:20: +3
[13-05-28 21:53:43.0133] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.967, 00:24:1d:89:06:20: +0
[13-05-28 21:53:44.0162] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.969, 00:24:1d:89:06:20: -1
[13-05-28 21:53:45.0103] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.970, 00:24:1d:89:06:20: -2
[13-05-28 21:53:46.0134] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.971, 00:24:1d:89:06:20: -3
[13-05-28 21:53:47.0163] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.971, 00:24:1d:89:06:20: -2
[13-05-28 21:53:48.0191] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.970, 00:24:1d:89:06:20: -2
[13-05-28 21:53:49.0075] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.973, 00:24:1d:89:06:20: -5
[13-05-28 21:53:50.0145] Slim::Player::StreamingController::_CheckSync (526) playPoints: b8:27:eb:ad:a7:7b: 1369769752.972, 00:24:1d:89:06:20: -3
[13-05-28 21:53:51.0039] Slim::Player::Player::trackJiffiesEpoch (981) 00:24:1d:89:06:20 adjust jiffies epoch +0.001s