Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
If it were me, before Looking to commercialise any product based on the work of Adrian Smith, I'd take legal advice specifically on the use of GPL v3 as the basis for a commercial product, as there may be implications as to releasing source etc, and the commercialisation of Adrian's work was against what the original intent was of squeezelite. Also looking at some of these changes (that mean absolutely nothing to me as I'm no audiofile), they are catering for a very narrow use case. Adrian was always careful with the changes he implemented in squeezelite to keep the code tight and be useful in as wide number of use cases as possible - and his vision helped to create this active community on the Logitech forums, which I'm indebted to. I would like to see whats left of the Logitech community flourish, but in reality, the majority of users are after simple easy to use hardware/software that supports the music services they subscribe to. LMS (and squeezelite) was/is great but these days there are many different more convenient ways to stream audio at high quality throughput the home. It doesn't really matter how enthusiastic the remaining community is - if the solution isn't in touch with the masses - it will fail as music services become less open and more about the commercial tie-ins and partnerships. And lets not forget the reality is people who still frequent these forums are not your average class of user - they are enthusiasts but they are not typical of the overall music streaming userbase. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
just in case any of you guys don't follow the Spotify plugin forum, it looks like libspotify was depreciated back in May 2015; http://forums.slimdevices.com/showthread.php?79706-Announce-Spotify-Premium-Plugin-(Beta)=833100=1#post833100 not good news IMHO and will effectively mark the end of the line for many. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
does anyone happen to know if this is Adrian?; https://uk.linkedin.com/pub/adrian-smith/24/194/306 can someone that knows him personally, maybe just try and reach out to him via facebook/linkedin etc to see if he's ok. I have tried emailing him back in April but never received a reply. Hopefully he's fine - he is certainly missed on these forums - I think we all respect his work and the contribution he has made to the community. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Hi, I have 2 rpi2s each with HiFi berry DAC+ cards on them. Running raspbian. I modify the squeezelite priority with a chrt -f -p 99 processid. I get perfect sync under Spotify using triodes plugin. But with radio streaming I get drift over time which turns into an annoying echo. Why is the sync drift only apparent under streaming radio? Is this as good as it gets under squeezelite or is there anything I can do? ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
has anyone considered using an HDMI audio extractor to take the HDMI from a raspberry pi model 2 and then configure ALSA into 4 separate stereo pairs and then run 4 instances of squeezelite to drive 4 independent zones? The HDMI audio on the pi has always been superb and form what I understand, every channel on the 7.1 setup can technically run up to 192hz (please correct me if I'm wrong). a quick search turns up this? http://www.mcmelectronics.com/product/STELLAR-LABS-33-11685-/33-11685 I'd be every interested if anyone has gone down this route or if anyone can see any reason why it wouldn't work. It looks like some people have done things very similar with ALSA; http://ubuntuforums.org/archive/index.php/t-1952124.html ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
just in-case this helps anyone... I have switched to running Squeezelite on 2xRas Pi 2s. I was having random audio drop outs on hdmi which appeared to be impacting on the sync. The fix was simple; config_hdmi_boost=4 in the config.txt in the root of the SDcard. I'm also using precision time protocol (PTP) on the RPIs to maintain accurate sync and have LMS running on the master server. PTP appears to be able to maintain sync down to about 1/100 of a second between multiple PIs. PI1 is connected via HDMI to my Onkyo receiver, PI2 is analogue sound port to lineinput on my win7PC and software mixing audio into the windows output sounds. On the master server (both running raspbian); Code: $ sudo apt-get install ptpd $ sudo vi /etc/default/ptpd # /etc/default/ptpd # Set to yes to actually start ptpd automatically START_DAEMON=yes # Add command line options for ptpd PTPD_OPTS=-b eth0 -h and then on the clock slaves; Code: $ sudo apt-get install ptpd $ sudo vi /etc/default/ptpd # /etc/default/ptpd # Set to yes to actually start ptpd automatically START_DAEMON=yes # Add command line options for ptpd PTPD_OPTS=-g -b eth0 -h and then to install the ptpd service to start at boot time; Code: $ sudo insserv ptpd I've have streaming radio running (via an RTMP source using BPAs excellent xplay plugin using VLC for transcoding) and there hasn't been a single player sync correction in the last two hours, so I think my system is finally starting to work it should. I should be able to improve things further once the two HifiBerry cards I've ordered arrive and I expect I should be able to drive both the HifiBerry ALSA output and the HDMI output simultaneously to give me more audio zones. I really like the work that Gramofon are doing - (I believe Allplay sync was finally pushed in the last week), but I like the open source aspect of the squeezebox architecture which makes everything possible and removes all restrictions. Has anyone been in touch with Adrian aka Triode? I hope he is OK - it would be great to see him on the forums again. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
bpa wrote: I don't think that make sense - sync is done on the stream that comes from transcoding - so vlc etc. shouldn't matter. Enable logging of sync protocol to see what is happening. Are all the sync players the exact same hardware and network connections. Thanks. So if my understanding is correct, the sync protocol is dependant on the players reporting accurate syncd clock signals? In my case (until the ALSA rpi changes to allow both HDMI and analog to work at the same time), I'm continuing to use 3 Squeezelite clients running as virtual machines, and I suspect the issue I'm experiencing is that there doesn't seem to be an easy of of having a stable clock source in virtual machines. I have disabled VMware forced time sync to the debian guests and I have disabled NTP in the guests and have switched to ptp (precision time protocol), so on my clock master; ptpd -c -h -D and on the clients I'm running; ptpd -c -h -g -D so the clocks are kept in sync. I have added clock=pit to the grub settings to supposedly prevent lost ticks; vi /etc/default/grub GRUB_CMDLINE_LINUX_DEFAULT=quiet clock=pit update-grub I switch up the debugging on LMS for the sync protocol in debug mode but I'm still see skips that are just happening too often. I have my sync adjustment set to 10ms. Has anyone ever had perfect sync on LMS over an extended period of time (like hours etc) on not squeezebox equipment? I'm not talking nearly perfect, I'm talking Sonos quality multi zone sync without echo etc? I'm just trying to understand if I'm battling with clock stability under virtual machines (highly likely) or if I'm also battling with flaws in the LMS sync protocols? Any comments would be appreciated. Maybe this is the first type of workload that I've come across that isn't suited to running under virtual machines. Code: [15-03-09 09:58:46.0024] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.097, 00:0c:29:b3:3e:85:-3, 00:0c:29:e9:46:6a: +12 [15-03-09 09:58:46.0030] Slim::Player::StreamingController::_CheckSync (559) 00:0c:29:e9:46:6a resync: skipAhead 15ms [15-03-09 09:58:48.0049] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.107, 00:0c:29:b3:3e:85:-4, 00:0c:29:e9:46:6a: -15 [15-03-09 09:58:48.0051] Slim::Player::StreamingController::_CheckSync (559) 00:0c:29:d8:dc:f7 resync: skipAhead 15ms [15-03-09 09:58:48.0054] Slim::Player::StreamingController::_CheckSync (559) 00:0c:29:b3:3e:85 resync: skipAhead 11ms [15-03-09 09:58:51.0035] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.088, 00:0c:29:b3:3e:85:-3, 00:0c:29:e9:46:6a:+9 [15-03-09 09:58:51.0039] Slim::Player::StreamingController::_CheckSync (559) 00:0c:29:e9:46:6a resync: skipAhead 12ms [15-03-09 09:58:53.0074] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.087, 00:0c:29:b3:3e:85:+5, 00:0c:29:e9:46:6a:+5 [15-03-09 09:58:54.0021] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.086, 00:0c:29:b3:3e:85: +14, 00:0c:29:e9:46:6a:+3 [15-03-09 09:58:54.0027] Slim::Player::StreamingController::_CheckSync (559) 00:0c:29:b3:3e:85 resync: skipAhead 14ms [15-03-09 09:58:56.0054] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.095, 00:0c:29:b3:3e:85: -11, 00:0c:29:e9:46:6a:-8 [15-03-09 09:58:56.0056] Slim::Player::StreamingController::_CheckSync (559) 00:0c:29:d8:dc:f7 resync: skipAhead 11ms [15-03-09 09:58:58.0030] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.083, 00:0c:29:b3:3e:85:+6, 00:0c:29:e9:46:6a: +10 [15-03-09 09:58:58.0035] Slim::Player::StreamingController::_CheckSync (559) 00:0c:29:e9:46:6a resync: skipAhead 10ms [15-03-09 09:59:00.0057] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.082, 00:0c:29:b3:3e:85:+5, 00:0c:29:e9:46:6a:-2 [15-03-09 09:59:01.0066] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.081, 00:0c:29:b3:3e:85: +14, 00:0c:29:e9:46:6a:+6 [15-03-09 09:59:01.0068] Slim::Player::StreamingController::_CheckSync (559) 00:0c:29:b3:3e:85 resync: skipAhead 14ms [15-03-09 09:59:03.0041] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.090, 00:0c:29:b3:3e:85: -10, 00:0c:29:e9:46:6a:-4 [15-03-09 09:59:03.0061] Slim::Player::StreamingController::_CheckSync (559) 00:0c:29:d8:dc:f7 resync: skipAhead 10ms [15-03-09 09:59:05.0108] Slim::Player::StreamingController::_CheckSync (526) playPoints: 00:0c:29:d8:dc:f7: 1425847660.078, 00:0c:29:b3:3e:85:-3, 00:0c:29:e9:46:6a: +13 [15-03-09 09:59:05.0110] Slim::Player::StreamingController::_CheckSync
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
JackOfAll wrote: I just noticed this 'ALSA: dedicated devices for HDMI and analog audio' (https://github.com/raspberrypi/linux/issues/847) on Pi github issues list. Which hopefully means, popcornmix will modify the Pi alsa driver so you can use both outputs simultaneously, rather than having to flip the routing switch and be restricted to one or the other, at some point in the future. brilliant. I think that's exactly what I need - I look forward to the changes being upstreamed. And now for a sync question which I'm sure is obvious to some of you. On Spotify feeds, I find sync is more or less OK as the feed is in the form of discreet tracks which I believe is important for the sync protocols using by Squeezelite. However, I listen to streaming radio (using BPAs xplay plugin as the streams I listen to are rtmp based) and I find the sync none existant between multiple Squeezelite players in a sync group. I believe this is because vlc is realtime transcoding the rtmp feed and pipes it into a single stream that LMS can understand. Is there a way of forcing vlc to chunk the stream into discreet tracks somehow to help maintain sync across multiple players every few minutes? I'd hate to be defeated by this sync issue and throw in the towel for Sonos/Allplay etc, but I'm close ;-( ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
mudlark wrote: why not use synchronise and two Pis? thanks, that is what I'll probably end up doing in the short term as I currently have 2xrpi2 and 1xrpi but it just feels like I'm under utilising the capabilities of the pi especially the rpi2 ;-) I was just hoping to better the 3 x sync'd zones I have at the moment (virtualised debian instances and pass-through sound hardware) off my main windows based HTPC. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
answering my own question on separate output on HDMI and on analogue with different zones on the rpi... after much research it appears that rpi and rpi2 can not play different sound to both HDMI and to the analogue 3.5 jack at the same time, therefor it's not possible to achieve a 2 zone rpi player (one zone for HDMI, other on 3.5) without an additional DAC or sound device. The rpi can only switch a single output from either the HDMI or 3.5 jack and direct the audio stream there. The issue is apparently a hardware limitation on the rpi. http://raspberrypi.stackexchange.com/questions/7955/play-2-sounds-simultaneous-hdmi-analog Oh well... back to running a single rpi2 per zone until I can find a suitable DAC. Does anyone know of a cheap 8 channel DAC that I could split into 4 stereo pairs and drive 4 zones off a single rpi2? ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
JackOfAll wrote: Have you tried -o hw:CARD=ALSA,DEV=1 I think HDMI is device 1 of card 0. thanks. Great stuff. Unfortunately I can't get any output out of squeezelite when I do this; I'm guessing this is to do with the way XBian is sharing the audio or perhaps I haven't got the correct package dependencies for Spotify under XBian - I'll keep testing. Code: $ aplay -l List of PLAYBACK Hardware Devices card 0: ALSA [bcm2835 ALSA], device 0: bcm2835 ALSA [bcm2835 ALSA] Subdevices: 8/8 Subdevice #0: subdevice #0 Subdevice #1: subdevice #1 Subdevice #2: subdevice #2 Subdevice #3: subdevice #3 Subdevice #4: subdevice #4 Subdevice #5: subdevice #5 Subdevice #6: subdevice #6 Subdevice #7: subdevice #7 card 0: ALSA [bcm2835 ALSA], device 1: bcm2835 ALSA [bcm2835 IEC958/HDMI] Subdevices: 1/1 Subdevice #0: subdevice #0 $ ./squeezelite-armv6hf -l Output devices: null - Discard all samples (playback) or generate zero samples (capture) default:CARD=ALSA - bcm2835 ALSA, bcm2835 ALSA - Default Audio Device sysdefault:CARD=ALSA - bcm2835 ALSA, bcm2835 ALSA - Default Audio Device $ /home/xbian/squeezelite-armv6hf -o hw:CARD=ALSA,DEV=1 -n RPI-Lounge -a 100 -r 384000 -d all=debug -P /tmp/squeezelite.lounge.pid -m ab:cd:ef:aa:bb:cc -f /tmp/squeezelite.lounge.log -s 192.168.3.101 -z $ /home/xbian/squeezelite-armv6hf -o hw:CARD=ALSA,DEV=0 -n RPI-Deck -a 100 -r 384000 -d all=debug -P /tmp/squeezelite.deck.pid -m ab:cd:ef:aa:bb:cd -f /tmp/squeezelite.deck.log -s 192.168.3.101 -z ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
JackOfAll wrote: Triode's pre-compiled armv6 binary should work fine if you don't want to compile your own. Grumpy Bob wrote: I've got a Pi2 running the armv6 squeezelite binary on Raspbian. Seems fine, though I'm looking forward to a Pi2 version of piCorePlayer! Robert sorry guys finally got around to testing this. I started with OpenElec image on the rpi2 but found it a little limiting for various reasons. I switched to xbian and now I can run up the squeezelite binary and after I inject the drivers for the sound; sudo modprobe snd-bcm2835, I can see the device; Code: # ./squeezelite-armv6hf -l Output devices: null - Discard all samples (playback) or generate zero samples (capture) default:CARD=ALSA - bcm2835 ALSA, bcm2835 ALSA - Default Audio Device sysdefault:CARD=ALSA - bcm2835 ALSA, bcm2835 ALSA - Default Audio Device but what I want is to be able to see both the HDMI and analogue audio devices as two separate devices together - what I wanted to do was to run up 2 instances of squeezelite - the first zone being the analogue output, the second zone being the HDMI output - is this possible on the rpi2? If so any ideas? The annoying thing is that I can do this very easily by running 2 separate Debian VMs on my main Windows 7 media centre - the first VM has the sound device connected to the analogue speaker, the second VM has the sound device mixed into the HDMI audio stream. Has anyone tried this before? On my debian VMs I see the following audio devices available on standard commodity PC desktop hardware; Code: # ./squeezelite -l Output devices: null - Discard all samples (playback) or generate zero samples (capture) default:CARD=AudioPCI - Ensoniq AudioPCI, ES1371 DAC2/ADC - Default Audio Device sysdefault:CARD=AudioPCI - Ensoniq AudioPCI, ES1371 DAC2/ADC - Default Audio Device front:CARD=AudioPCI,DEV=0 - Ensoniq AudioPCI, ES1371 DAC2/ADC - Front speakers rear:CARD=AudioPCI,DEV=0 - Ensoniq AudioPCI, ES1371 DAC1 - Rear speakers surround40:CARD=AudioPCI,DEV=0 - Ensoniq AudioPCI, ES1371 DAC2/ADC - 4.0 Surround output to Front and Rear speakers iec958:CARD=AudioPCI,DEV=0 - Ensoniq AudioPCI, ES1371 DAC2/ADC - IEC958 (S/PDIF) Digital Audio Output thanks ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
hi, xmas has come early and 2 x rpi 2 have arrived! I've decided to use OpenElec as the distribution as it seems to take a lot of the pain out and allows me to integrate with Plex and Live subscription TV (via Dvblogic). Is there anything special I need to do to get squeezelite running on the thing? Will I need to recompile for the rpi2 armv7 architecture? thanks. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Compiled squeezelite from git master version for Debian x86. Looking great! The unload of alsa is a great addition and seems to work great on virtualized Debian instances under VMware and the pid file changes make the start up and shutdown scripts much cleaner. Nice work Adrian. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
JackOfAll wrote: The M2 uses the AllWinner A31 rather than A20, I think, so not sure what it is using for codec. The on-board codec, (24 bit DAC), actually built into the A20 SoC, is one of the best kept secrets in terms of SQ. Sound quality is very good, compared to sgtl5000 and some of the other junk typically used as external codec with other SoC's. So if AllWinner kept that in the A31, and the M2 board doesn't use an external codec/DAC, suspect sound will be good. thanks. Interesting. I've been able to find the data sheets for the A20 and A31, and they look mighty similar except the A31 seems to have improved audio over the A20. I wonder if the Banana Pi M2 (running the A31) and the Banana Pi (running the A20) are going to end up best of breed SqueezeLite platforms? I can't wait to get my hands on one! A20 datasheet; https://dl.linux-sunxi.org/A20/A20%20Brief%202013-02-27.pdf A31 datasheet; http://dl.linux-sunxi.org/A31/A31%20Datasheet%20-%20v1.00%20%282012-11-06%29.pdf - Two audio DAC channels - Stereo capless headphone drivers - Up to 100dBA SNR for DAC playback - 8KHz~192KHz DAC sample rate - Support analog/digital volume control on the A31, it says; Two sets I2S/PCM interfaces for baseband and Bluetooth which I guess could be of interest. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Has anyone been lucky enough to get one of the latest banana pi m2 units to test the onboard audio quality from squeezelite running on this? I see the qualcomm AllPlay technology seems to be gaining traction. How does the sync protocol and reliability on this compare against the squeezebox? ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Hi, I've been running SqueezeLite since the beginning and after periods of SqueezeLite inactivity (several hours) I hear cracking/white noise.. I have been managing this issue using the PowerSave plugin to power off the SqueezeLite instances after 15 minutes of inactivity. This usually resolves the problem but not always. Sometime the only way I can restore functionality is to reboot the SqueezeLite instances. I'm not using a DAC - I'm running the Debian Squeezelite instances under VMware Workstation and using the VMware virtual sound device to mix the audio into the HDMI audio stream of my main Windows 7 Media Centre. There are a few very similar related issues documented on google code which seem to suggest that in periods of inactivity, silence is continuously pushed through the ALSA stack rather than nothing and it's this that may be linked to some memory related issues subsequently causing random failure. Adrian, is there any chance you could re-look at this and perhaps look at changing the behaviour of SqueezeLite during periods of silence? This is the one thing that is preventing SqueezeLite from being wife friendly! ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] piCoPlayer = Squeezelite on Microcore linux. .An embedded OS in RAM with Squeezelite
Hi, I'm currently running SqueezeLite on Debian as a set of x86 virtual machines under VMware workstation on different hosts. It has been working great. I like the idea of a ram only based distribution and wondered if you could build a version that could be downloaded as a VMware virtual appliance? It could make things easier in some situations. thanks! ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97803 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
moocow89 wrote: Thanks for the suggestion, I've tried a 64bit debian in vmware and it's no better sync-wise - do you specify any special parameters to squeezelite? I compiled 1.4 from scratch, and tried both: default- Playback/recording through the PulseAudio sound server sysdefault:CARD=AudioPCI - Ensoniq AudioPCI, ES1371 DAC2/ADC - Default Audio Device I think the difference between our systems is that I have disabled pulseaudio and are using ALSA but my audio devices are the same. This might be why you are still seeing sync issues, so it might be worth doing a quick google to find out how to disable pulseaudio (I can't find my build notes anywhere!) but I'm certainly no expert here. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
hi, for ages now I've been running 3 instances of squeezelite on debian VMs under VMware Workstation - all using Adrian's great Spotify plugin. It has been working perfectly. When I added a droid client (in the form of the excellent SqueezePlayer) I was constantly having issues with the SqueezePlayer client always starting first and could never get to the bottom of it. I've just been trying to understand why and came across this; http://blog.bryansmart.com/2012/02/16/low-latency-sound-for-vmware/ it appears that VMware is by default creating an additional buffer of 200ms (when the host is windows7 - my case) when it mixes the audio from the virtual audio device to the physical one. I've made the following changes to the vmx files on each of the squeezelite VMs; sound.autoDetect = FALSE sound.virtualDev = es1371 pciSound.playBuffer = 30 and now the sync is very close even at the start of each Spotify song. Anything less than a 30ms buffer on the VMware side seems to cause distortion. Are there any changes that could be made to the design of squeezelite/SqueezePlayer/LMS to allow for this type of additional buffer or is there a change I can make to the squeezelite configuration to take this into account but still preserve sync even at the start of each track? thanks! ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Triode wrote: Try adjusting the server parameters for the player on the server settings - player - synchronize web page. (I think the player audio delay may help) thanks for that. I've tried those settings for both the audio group (apart from the Android device) and the reverse - it just seems to increase the latency - and makes the SqueezePlayer client start even earlier than the others. It's strange as on a Spotify track, the players start to all sync ok within the first 10 seconds of the track (after skipping to the next track). I guess it's because they start out of sync by 40ms and then try and re-sync back. It must be the additional buffer that VMware is creating as part of the virtual sound card architecture that is causing the issue here. On the following track on a Spotify playlist, the players again start out of sync (it sounds as if the droid SqueezePlayer is starting 40ms before the rest of the audio group). Is the issue here an underlying issue with the Squeeze sync protocol not correctly dealing with fixed audio latency caused by the vmware buffering? I have the minimum sync adjustment set to 10ms if that makes a difference (I don't seem to be able to set it to less than this). ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
I'm running squeezelite under 32 bit Debian VMs under VMware workstation running on multiple Windows 7 PCs. Sync is perfect (I have no Squeezebox hardware as such) when using both Spotify plugin and Pandora and sound quality is great. When I add an android device (eg Nexus 7 2013 model running Squeeze Player or SB Player) to the sync group, I find sync drifting - this is primarily when I'm using Spotify plugin or Pandora (I have no local music anymore). When I make Squeeze Player the master of a sync group, sync appears better but still not perfect. Is there anything that can be done with Android devices/SqueezeLite to allow them to remain in sync with SqueezeLite better or is the whole Squeeze clients on Android a lost cause? As an aside, previously bluetooth streaming from android to bluetooth speakers while streaming from wifi used to be a cause of buffer issues but this now appears to have been resolved on the latest Nexus 7 tablets (issue is still there on a Samsung S3 running CM10.2) though. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
DJanGo wrote: Hi just take a blank sheet of Paper and sketch your Network to it. Then think about from where to where the streams goes. After that you know that you have more than one bottleneck. (And thats not the squeezeliteplayer) looks something like I dont think that can be fast... thanks. but the reality is virtualised debian VMs running squeezelite work fantastically well. The only issue I have is when I connect an Android device into the sync group. Originally I used to run squeezelite natively under windows but the issue I had was that the portaudio version (that runs under windows) did not maintain sync over time - since I switched to Debian VMs under VMware workstation I have no sync issues between multiple VMs on different physical machines, so it's just the sync to the android device that the issue is. It's an easy one to reproduce. I don't suspect squeezelite to be the cause - I suspect the issue is the different way android squeeze clients are integrated into android alsa. But the configuration could be common enough if it worked properly. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Triode wrote: Could you try squeezelite-i386-test which is on the download page? This is compiled with _FORTIFY_SOURCE disabled, which I believe removes the dependency on glib 2.15 when build on ubuntu. (I don't really want to do this, but its easier than having a debian vm to build it on) thanks for that - the test version works perfectly! The only way I could get the non test 1.3 i386 version was to uncompress the Ubuntu libc6_2.15-0ubuntu20_i386.deb file and then modify the LD_LIBRARY_PATH before starting the daemon - in my case; export LD_LIBRARY_PATH=/opt/squeezelite/lib/i386-linux-gnu but a simpler solution (like your test version) is much less hassle. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Hi, I've been running squeezelite v1.2 for ages under Debian on i386 - all working a charm. Today I tried to upgrade to the v1.3 squeezelite-i386 binaries/ When I try to run the binary, I get a message; ./squeezelite-i386: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ./squeezelite-i386) I'm not sure if this is related; http://stackoverflow.com/questions/10863613/how-to-upgrade-glibc-from-version-2-13-to-2-15-on-debian Is there any chance the binary could be recompiled in a form that will run under Debian? It would make it much easier for people like me? Thanks. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Triode wrote: Yep - pm me an email address and I can build you a test version if you want - what binary are you using? just in-case it helps anyone, I have now resolved this issue (crackling/no sound after squeezelite left powered on for extended period -ie. 5 hours without any activity on virtualised debian squeezelite clients under VMware under Win7). To get around the issue I'm now using the powersave plugin to put the squeezelite clients to sleep after 90 mins of inactivity on pause/stop - http://bitflip.net/squeezebox/ In the morning I find the sync group is powered off (due to the powersave plugin) so I just start it up and resume the playlist - all works great. thanks again to Triode and all the other people who've contributed to this great forum. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
I've been able to narrow down the problem of no sound/distorted sound after a paused playlist is left overnight. Here is how I can reproduce; - Start playing a spotify playlist (using Triode's plugin). - Pause the song - Leave everything for approx 8 hours (leaving all squeezelite clients running and powered on). - Attempt to unpause the playlist - No sound out of squeezelite for about 5-10 seconds after unpausing, then followed by whitenoise. - If the squeezelite clients are powered off/on around 3 times then audio commences as it should after playlist started again. Below shows what I think are the important sections from a all=debug trace: 21:33:52: SqueezeLite instance starts up 22:03:30: Spotify playlist started 22:03:42: Squeezelite playlist paused 07:58:33 (following day): Squeezelite playlist unpaused (about 5 secs of silense followed by white noise etc) Interestingly to me is that after an unpause the output buffer is immediately flushed (07:58:33). Could squeezelite perhaps be changed to unload alsa after a period of inactivity (say 2 hours), and then to load it again when requested - even if this added a few seconds to the start up, it would be preferable to the kids screaming of whitenoise at top volume in the lounge ;-) If I pause the playlist, then instead of leaving the squeezelite clients powered on, I power them off (through squeeze commander), then the following morning, I power them back on (again through squeeze commander), and then resume, everything works perfectly. I've checked the power_save mode on the sound card module and it's disabled along with all other powersavings inside the Debian Wheezy VM under VMware workstaion under Windows 7, so I don't believe the issue is power saving related. Any ideas? Thanks again - the combination of Triode's squeezelite+Spotify plugin is an unbeatable combination! [21:33:52.127870] stream_init:264 init stream [21:33:52.128190] stream_init:265 streambuf size: 2097152 [21:33:52.130481] output_init:1305 init output [21:33:52.130501] output_init:1308 outputbuf size: 3528000 [21:33:52.130542] output_init:1340 requested buffer_time: 2 period_count: 4 format: any mmap: 1 [21:33:52.138428] output_init:1366 output: sysdefault maxrate: 384000 [21:33:52.138494] output_init:1374 unable to lock memory: Cannot allocate memory [21:33:52.141184] output_init:1397 unable to set output sched fifo: Operation not permitted [21:33:52.141205] decode_init:101 init decode [21:33:52.141326] load_faad:557 loaded libfaad.so.2 [21:33:52.141768] load_vorbis:234 loaded libvorbisidec.so.1 [21:33:52.141957] load_flac:196 loaded libFLAC.so.8 [21:33:52.141971] register_pcm:191 using pcm [21:33:52.142047] load_mad:292 loaded libmad.so.0 [21:33:52.142165] slimproto:683 connecting to 192.168.1.101:3483 [21:33:52.142411] output_thread:583 open output device: sysdefault [21:33:52.142822] slimproto:705 connected [21:33:52.142836] sendHELO:109 mac: 00:0c:29:e9:46:6a [21:33:52.142842] sendHELO:111 cap: Model=squeezelite,ModelName=SqueezeLite,AccuratePlayPoints=1,HasDigitalOut=1,MaxSampleRate=384000,aac,ogg,flc,aif,pcm,mp3 [21:33:52.142933] sendSETDName:210 set playername: Lounge [21:33:52.147913] alsa_open:269 opened device sysdefault using format: S32_LE sample rate: 44100 mmap: 1 [21:33:52.147964] alsa_open:317 buffer time: 85328 period count: 4 buffer size: 3763 period size: 940 [21:33:52.149743] process:411 unhandled setd [21:33:52.149765] process:411 unhandled setd [21:33:52.149777] process:407 aude [21:33:52.149782] process_aude:338 enable spdif: 1 dac: 1 [21:33:52.149792] process:407 audg [21:33:52.149797] process_audg:355 audg gainL: 0 gainR: 0 adjust: 1 [21:33:52.527513] process:407 strm [22:03:26.479212] sendSTAT:151 STAT: STMt [22:03:30.508068] process:407 strm [22:03:30.508127] process_strm:219 strm command q [22:03:30.508141] output_flush:1411 flush output buffer [22:03:30.508166] sendSTAT:151 STAT: STMf [22:03:30.513666] process:407 audg [22:03:30.513705] process_audg:355 audg gainL: 65536 gainR: 65536 adjust: 1 [22:03:30.514455] process:407 strm [22:03:30.514479] process_strm:219 strm command s [22:03:30.514491] process_strm:284 strm s autostart: 2 transition period: 0 transition type: 2 [22:03:30.514505] sendSTAT:151 STAT: STMf [22:03:30.514679] codec_open:150 codec open: 'p' [22:03:30.514705] pcm_open:172 pcm size: 2 rate: 44100 chan: 2 bigendian: 0 [22:03:30.514787] stream_sock:352 connecting to 192.168.1.101:9005 [22:03:30.519084] stream_sock:381 header: GET spotify:track:0XzkemXSiXJa7VgDFPfU4S/stream.pcm?player=00%3A0c%3A29%3Ae9%3A46%3A6astart=6602sync=3id=166 SPOTSTREAM/1.0^M ^M [22:03:30.519114] sendSTAT:151 STAT: STMc [22:03:30.519132] process_strm:307 set fade mode: 2 [22:03:30.519157] process:407 audg [22:03:30.519168] process_audg:355 audg gainL: 65536 gainR: 65536 adjust: 1 [22:03:30.640173] process:407 strm [22:03:30.640222] process_strm:219 strm command t [22:03:30.640239] sendSTAT:151 STAT: STMt [22:03:30.949903] process:407 strm
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Triode wrote: Interesting Does this occur with flac as the codec? (codec_open:150 codec open: 'f') This should be the default for the spotify plugin, so assume you have disabled this? Are you able to build your own binary to try a change or two? thanks. I've checked LMSSettingsAdvancedSpotifyPCM-Native/Disabled.. and I have this set to Native. I Don't see any flac settings for that. Should I set this to Disabled to get Spotify using flac? I can try to build a binary, is it as simple as? # apt-get -y install build-essential git wget checkinstall libasound2-dev libmad0-dev libflac-dev libogg-dev libvorbis-dev libfaad-dev libmpg123-dev # cd ~ # git clone https://code.google.com/p/squeezelite/ # cd ./squeezelite # make clean # make thanks again. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
psketch wrote: Hi John Yes - completely agree that HDMI is a completely different option than the built in audio. Built in is functional but really basic, but the HDMI output is really clean and works very well. I don't get any pops, cracks etc.. Interesting what you say about no sound after it being unused for a while - I've also seen that, but also saw it when running Squeezeslave as well, so I think it's the audio stack on the Pi. Interestingly, I didn't get this on the very old Pi firmwares (i.e. the first HF builds). They seemed to introduce this bit of a problem when trying to fix audio quality on the built in audio (not hdmi). pete S Sorry to bring this up again. I'm running SqueezeLite under VMware workstation with Debian VMs. All working perfectly apart from this no sound after a while (around 8 hours or more). If I press the power on/off button around 3 times from LMS on each squeezelite client, eventually sound will come through with some initial popping and white noise. Did anyone ever find a solution to this? ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Triode wrote: Doubt it is the same problem as seen with the hdmi as this is a driver issue. Have you tried enabling debugging and seeing if there are any changes after 8 hours? thanks. I see the same issue on both my main HTPC running 2 VMs (which is using HDMI through to the AV for VM1, and stereo to AV zone 2 for VM2), and to another PC running VM3 which is stereo to powered speakers. I'll switch on debugging and see what pops up. The fact the repeated power on/off of the squeezelite clients seems to fix it would presumably mean the re-opening of the alsa device is what fixes the issue? ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
hi, I'm running squeezelite under Debian Wheezy as VMs under VMware workstation. It's all working really well. One thing I'm finding though is that I have 3 VMs with 3 squeezelite instances permanently in a sync group. If I stop the music at night and then leave everything until the morning (nothing powered off), I'm unable to play any music until I unsync the group and then resync it again. The behavior seems quite predicable. Does anyone have any ideas on this? I'm thinking it may be to do with some power saving mode or similar inside the VMs? Has anyone seen this on either physical or virtual machines? ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
BreakTheStatic wrote: Hey guys, I was toying with the idea running a Squeezelite-only ecosystem utilizing several existing Win7 8 machines I currently have running (I need to run WMC to get my copy-protected cable channels so Linux on these is a no-go). Running Squeezelite on these machines, I've had tons of sync issues. Different start times (somewhat mitigated w/ setting an audio delay in settings, but not ideal), small drift during songs, and very large drift when resuming from pause. I've read this thread and see that the Windows audio stack is not ideal for sync due to the lack of control of the buffer. As a cheap solution, I was thinking of just getting a few Raspberry Pis and running them next to my PCs (powered off the PCs usb). Would a RPi-only network (without any actual SB hardware) handle sync fine? I see that Triode has stated that sync consistency is way better on linux than Windows. I'm tempted to wipe a few of my laptops and install linux to test this out, but figured that if people are already running this setup, it might be easier to just ask. Thanks for any help you guys can provide! I was also thinking along the same lines as I had similar sync issues until today. Today I ran up Vmware workstation on a win7 pc and spun up a 1gb ram Centos 6.4 vm and ran squeezelite under linux. I was staggered when 2 seperate linux vms on separate win7 pcs synced perfectly and kept in sync. I had to start each virtualised squeezelite client up with a -a 1000:8 parameter to prevent audio break up, but after that it was great. I'll run some more tests but it looks like virtualised linux is a go as a squeezeclient. It did make me wonder if it was technically possible to compile squeezelite under cygwin for an easier and more reliable experience under windows. ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
ashleyw wrote: I was also thinking along the same lines as I had similar sync issues until today. Today I ran up Vmware workstation on a win7 pc and spun up a 1gb ram Centos 6.4 vm and ran squeezelite under linux. I was staggered when 2 seperate linux vms on separate win7 pcs synced perfectly and kept in sync. I had to start each virtualised squeezelite client up with a -a 1000:8 parameter to prevent audio break up, but after that it was great. I'll run some more tests but it looks like virtualised linux is a go as a squeezeclient. It did make me wonder if it was technically possible to compile squeezelite under cygwin for an easier and more reliable experience under windows. I had a couple of issues starting squeezelite under CentOS without logging onto the Gnome desktop, so I ditched CentOS and spun up a 32bit Debian VM with 512MB ram. The only thing I needed to do was a apt-get install libasound2 alsa-utils alsa-oss, and then run up alsamxer and press m (to unmute) on the Master and PCM and push the volume of both Master and PCM up to 100. Then alsactl store to save the settings across reboots. I created a squeezelite start up based on this; http://linux.freethenoise.com/logitechmediaserver/ and now everything is working as expected. I copied the VM to another 2 machines and adjusted the sound cards on each one and now they appear to all be workingh fine! thanks for a great thread! ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
I have been running some further tests on syncing. It appears that when a Spotify playlist is selected (via Triode's Spotify plugin) to a sync group of 3 x windows squeezelite clients that sync seems ok. However, after pausing the music (by SqueezeCommander), it's after restarting again that the sync seems to start to drift quite quickly. Are there issues known issues with pausing or fast forwarding a Spotify feed and sync? I see the same type of issue with Pandora as well. Any ideas? I'm running Squeezelite with this level of debugging on - do I need to increase this to see any useful information? squeezelite-win.exe -n Office -m aa:bb:cc:12:34:56 -o default -d output=debug -f c:\squeezelite\Office.log This is an example of what I see in the log files - what should I be looking for in relation to sync issues? [08:35:17.748] pa_callback:773 track start sample rate: 44100 replay_gain: 29952 [08:35:34.002] pa_callback:705 skip 573 of 573 frames [08:35:58.008] pa_callback:705 skip 573 of 573 frames [08:36:09.009] pa_callback:705 skip 485 of 485 frames [08:36:27.010] pa_callback:705 skip 485 of 485 frames [08:36:33.015] pa_callback:705 skip 926 of 926 frames [08:36:57.019] pa_callback:705 skip 970 of 970 frames [08:37:17.012] pa_callback:705 skip 485 of 485 frames [08:37:21.004] pa_callback:705 skip 573 of 573 frames [08:37:35.012] pa_callback:705 skip 529 of 529 frames [08:37:48.022] pa_callback:705 skip 1058 of 1058 frames [08:37:58.022] pa_callback:705 skip 705 of 705 frames [08:38:09.012] pa_callback:705 skip 485 of 485 frames [08:38:23.032] pa_callback:705 skip 749 of 749 frames [08:38:33.022] pa_callback:705 skip 705 of 705 frames [08:38:43.022] pa_callback:705 skip 529 of 529 frames [08:38:47.012] pa_callback:705 skip 573 of 573 frames [08:39:07.562] pa_callback:773 track start sample rate: 44100 replay_gain: 31744 thanks! ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Triode wrote: Probably needs to be Linux running natively to get accurate feedback on the buffer fill which is what sync needs. Do you see any resyncing going on? (Skip messages in the debug) While I'm busy trying to work out how I'm going to fit in a Linux PC into my HTPC architecture, I just want to check... I wonder if the sync issues I'm having are because I have three different squeezelite clients (all under windows) and I'm syncing the 3 into a sync group with one of them being the master. I have no physical squeezebox hardware. Har far does the sync code work when the master is a squeezelite instance and not a real squeezebox? Has this config been tested? Are other people seeing sync issues? Problem for me is that my HTPCs will unfortunately always be Windows 7 (because of TMT5/AnyDVD/3D bluray/bluray menus/DVBLogic combination) so my house is not in Linux land so I'm stuck with the capabilities of Windows 7. Is there any further squeezelite work that can be done on the Windows port of it to tune sync etc? ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Triode wrote: I think I've said before here - my aim on linux with alsa is to get sync as close as possible to a hardware player. On windows and OSX I am using an additional library (portaudio) which provides less control over playback buffers and so sync will never be as good. HI, I have been playing Spotify feeds over the weekend - the sync with multiple instances of squeezelite under windows quickly starts to go off (sync noticeably out within 10 minutes across 3 squeezelite windows instances). I switched debugging on and saw nothing to indicate an issue (even though sync was around 1 second out). Is there anyone else who can run up mutliple instances of squeezelite using say HDMI Audio + analogue sound on the same windows host to see if they can reproduce the issue and see what is going on? To help troubleshoot, I've switched LMS to run under CentOS (as a VM) and this has made no difference to syncing (I had LMS running under Win7 64bit before). I'm experimenting to see if I can run up a minimal CentOS VM specifically for SqueezeLite but I'm have issues getting any audio through to the CentOS guest (squeezelite starts up fine but just no output) - I'm using VMware workstation 9. Has anyone else got squeezelite running as a linux guest to a windows host using VMware workstation and if so is the sync any improvement over the windows based squeezelite sync? cheers ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Triode wrote: It's likely that the crystals on the sound cards are slightly different frequencies. However squeezelite is intended to skip frames to take account of this. Do you see skips if you enable output debugging? thanks, I'll collect some debug logs over the next few days. As sync issues seem to be the number 1 problem that most SB users experience, has any research been done to see what if any options are available to replace the current sync logic with something that is more suited to using cheap kit which could have variable crystal stability? Even if there was an option to sync back the players in the gaps between each song, it would help a lot. SqueezeLite is so close to being a viable open alternative to Sonos - for me 100% reliable sync across multiple zones is the last part of the puzzle (and having a Pandora plugin not dependent on mysb.com!). ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
Thanks Triode, v1.1 under windows also working great for me. One niggling issue though... I've been playing a lot of Pandora and Spotify recently. I've added some speakers to my outside area and created a new zone running a second instance of SqueezeLite with different mac address targeting a different sound device on the PC - this works well. However, after a period of time (say 30 mins or more) the sync between the 2 instances slowly starts to drift - a virtual power on/off of the squeezelite instance seems to temporarily fix the issue. I have LMS running on another windows box on the same physical switch. As the 2 zones are 2 separate instances on the same PC, how is it possible that the two instances can get out of sync over time and what can be done to fix the issue? ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
Re: [SlimDevices: Unix] Announce: Squeezelite - a small headless squeezeplay emulator for linux (alsa only)
I'm running squeezelite under windows 7 64bit as a service using nssm. All works perfectly.. Only issue is when I play a bluray and bit stream audio to my receiver (using TMT5), I find that after a bluray has stopped, squeezecommander doesn't see the squeezelite client anymore despite the fact the service is still running. I'm guessing this is to do with bit streaming taking exclusive use of the sound device and then not releasing it properly afterwards. Strangely normal windows sounds are fine after the bluray has stopped though. To get the squeezelite client running again, I have to restart the service. Anyone else see similar types of issues? Any ideas on a solution? ashleyw's Profile: http://forums.slimdevices.com/member.php?userid=58923 View this thread: http://forums.slimdevices.com/showthread.php?t=97046 ___ unix mailing list unix@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/unix
