squeezeslave enhancements

[Dominique]

Hi all,

I'm new to this forum and to slimserver/squeezebox in general. I just bought a squeezebox and built a small fanless server (Via Epia-EX, Xubuntu 7.04) that I want to use as a player as well.

For the server-side player, SoftSqueeze doesn't quite cut it for me: I want to use the web interface to control playback as it shows more info at once and, with some css touch-ups to the Nokia770 skin, makes a workable approximation of a 10-foot UI. I'm aware of SoftSqueeze's headless skin, but its unstability (freeze, drops connection) made it non-appealing.

So I gave squeezeslave a go, and found it was equally unpredictable, but had the net advantage of being lightweigt and easy to understand. So I fixed it and here's my patch, which Richard Titmuss asked me to post here.

Here's a summary of what I have done:

. Fixed two race-conditions leading to mutex deadlocks during startup.
. Fixed a startup deadlock happening when starting up with slimserver not running.
. Implemented keep-alive status reporting when playback is paused/stopped, without which slimserver 6.5.x drops the connection after 15-20s.
. Documented all the options so that -h/--help outputs something useful.
. Fixed a few signed/unsigned char warnings.
. Implemented a signal handler which makes it possible to background/daemonize squeezeslave and stop it with SIGTERM (-s/--signal).

I'm aware of another solution to this last problem that has been posted here, but its implementation uses an infinite loop that is unsuitable for performing a clean shutdown.

There are a few items that I'd like to address eventually:

. Use of a log file rather than print to stderr.
. More detailed error messages. For example, if I start a second instance of squeezeslave by mistake, I get "PortAudio error: Host error".
. Proper startup script (more on this below).

I have not yet found a suitable place to start squeezeslave as a daemon (with start-stop-daemon) when the computer boots. The machine's startup scripts seem a logical place, but this is usually too early. Depending on the boot speed and the number of boot tasks to do (respectively fast and little, for me), squeezes
lave ends up starting before slimserver has open its communications, which causes it to exit. I guess a retry-timeout option could do it, but I'd like to hear what you think.

A few final notes:

1. I have only tried this on Linux. I believe my touch-ups only use ANSI APIs (signal(), pause()), but I'm in no position to test on other configurations.
2. Because I'm changing files in .../slimproto and .../slimaudio, there will be consequences in the Java library (no API changes, though). I believe the conse
quence is that SoftSqueeze should work better, but I don't know how to test this.
3. This was my first time using subversion: hope my patch makes sense.

Hope this will be as useful to you as it is for me!

Dominique

[Mark Lanctot]

Very nice Dominique, thank you!

I don't really know how to apply a patch, so I've started a thread off the developers' list here:

http://forums.slimdevices.com/showthread.php?p=219924#post219924

[Robin Bowes]

Dominique wrote:

> There are a few items that I'd like to address eventually:
>
> . Use of a log file rather than print to stderr.

Why not simply re-direct stderr to a file using 2>& or similar?

> . More detailed error messages. For example, if I start a second
> instance of squeezeslave by mistake, I get "PortAudio error: Host
> error".
> . Proper startup script (more on this below).
>
> I have not yet found a suitable place to start squeezeslave as a daemon
> (with start-stop-daemon) when the computer boots. The machine's startup
> scripts seem a logical place, but this is usually too early. Depending
> on the boot speed and the number of boot tasks to do (respectively fast
> and little, for me), squeezes
> lave ends up starting before slimserver has open its communications,
> which causes it to exit. I guess a retry-timeout option could do it,
> but I'd like to hear what you think.

Use runit (http://smarden.org/runit/). It will start the app and restart
if it can't dies.

> +-------------------------------------------------------------------+
> |Filename: squeezeslave_patch.txt |
> |Download: http://forums.slimdevices.com/attachment.php?attachmentid=3131|
> +-------------------------------------------------------------------+

I applied your patch and committed it as svn r12523.

I have not tested it.

R.

[JJZolx]

Where will we find the new Windows binary when its made available?

[Dominique]

Thanks a lot for committing this. How does it work if I want to work some more in squeezeslave: should I always post proposed patches here? And more importantly, how does the review process work: is there someone in charge that will go through my changes to make sure they don't break anything or contradict basic rules I am unaware of?

About your logging question:

Using a log file seems more portable. I really don't mind redirections in my own little Linux world, but doesn't this leave Windows user aside?

And thanks for the pointer to runit: I'll give it a try as soon as possible.

Dominique

[Robin Bowes]

Dominique wrote:
> Thanks a lot for committing this. How does it work if I want to work
> some more in squeezeslave: should I always post proposed patches here?
> And more importantly, how does the review process work: is there someone
> in charge that will go through my changes to make sure they don't break
> anything or contradict basic rules I am unaware of?

I'm not really the right person to ask that. I glanced through your code
and it seemed to make sense but I'm not really a C coder so I can't
examine it in any details. Also, I don't have a build environment setup
to build it myself.

>
> About your logging question:
>
> Using a log file seems more portable. I really don't mind redirections
> in my own little Linux world, but doesn't this leave Windows user
> aside?

Isn't squeezeslave aimed at console-based computers, i.e. it is unlikely
to be used on Windows? Ah, but then I see JJZolz wants a windows binary.

I don't know all that much about how redirection works on Windows, but I
think you can re-direct stderr to a file like on linux.

R.

[NigelMSB]

I don't know all that much about how redirection works on Windows, but I think you can re-direct stderr to a file like on linux.">file.txt" redirects STDOUT, and "2>file.txt" redirects STDERR (and, I think, STDOUT).

[JJZolx]

Isn't squeezeslave aimed at console-based computers, i.e. it is unlikely
to be used on Windows? Ah, but then I see JJZolz wants a windows binary.

I think people are just looking for a client that is lighter weight and maybe a bit more reliable than Softsqueeze, whatever the environment. I run either Softsqueeze headless or Squeezeslave as a Windows service and then use the web interface for playback control. Squeezeslave looks like it has the potential to be a good replacement for Softsqueeze headless, but to date it hasn't proven as stable for me.

[rtitmuss]

Dominique this is great thanks. I've sent you a PM.

I am really busy (honestly really really busy) right now, so I won't be able to post updated binaries on all platforms for a while. However I could upload any binaries compiled by other people to the sourceforge site if you can send them to me.

Thanks,
Richard

[Dominique]

The "lightness" of squeezeslave is exactly what drew me to work on it. For me, at least, I can say it is now more stable than SoftSqueeze: no more freeze on start, no more connections dropped.

To me, it fills a niche in a specific setup:

I want my server machine to also be a player, with a nice looking UI and reasonably large fonts and that does more than emulate the 2-3 text-line of Squeezeboxes: I want about the same experience as a media center (well, the music part of it anyways). Browsing with cover art and seeing 12-15 lines of text makes the experience more enjoyable. To this date, only the web frontend coupled with a headless player fits the bill, although there is some sluggishness in the response time that I feel is inherent to a html solution. I may also look at how to integrate a remote-control to this, because a PC keyboard (even if it's wireless) is no fun carrying around just to navigate the playlist.

Give my fixes a try if you can, I hope they work more than just for me.

Dominique

[Dominique]

I'll send you my binary tonight. Are there any requirements about what version of the dependencies I use (libflac, libvorbis, libmad...)? I can't decide actually if I like it that these dependencies are staticly linked in the app... Simple to install and distribute, but takes more resources since there's not sharing, and users cannot benefit from fixes in the individual libraries until we recompile it for them.

Food for thought.

Dominique

[Dominique]

Hi all,

I have a linux-x86 squeezeslave binary ready since Friday night, but I cannot upload it to sourceforge. I guess there is some packaging to do as well (e.g.: license notice) but I am not familiar with the procedure.

Can anyone help?

Dominique

[ralphy]

Richard,

Can you add my Solaris 9 sparc squeezeslave binary to the sourceforge site?

http://paddockd.freeshell.org/squeezeslave-svn12533-sol9sparc.tar.gz

I've been using this patched version of squeezeslave on my Ultra 10 running Solaris 10 as well as on a Sunray with Solaris 9.

Now I can finally upgrade my 6.3.1 slimserver to the latest 6.5, thanks Dominique!

Ralphy.

[Dominique]

Hi ralphy,

Good to know the fix worked on Solaris as well. Richard is adding me to the SoftSqueeze sourceforge project so I can upload binaries by myself. Hopefully, I'll upload the Linux x86 tonight. At this point, if it's not done yet, I can upload your binary as well.

Stay tuned,

Dominique

[Dominique]

Hi all,

I have just uploaded the linux-x86 binary on sourceforge, as version 0.7.

Ralphy, I have tried to upload your file, but the link provided does not work for me. Tried with firefox and wget. If you point me the right way, I'll upload it as well.

Dominique

[ralphy]

Thanks Dominique,

I've updated the url in my original post.

Ralphy.

[Dominique]

Hi ralphy,

I have just uploaded your binary. I have updated the tar.gz so it includes the licence.

If anybody is in a position to create other binaries (windows, osx), send a note to this thread with the url and I will upload it to sourceforge.

Dominique

[oreillymj]

Any chance of a win32 build?

I'd have a go at compiling the source in VC++ if I could get my hands on all the files in a zip.

[ralphy]

I've checked out the latest softsqueeze and zipped up the source tree. It's about 20MB. Let me know once you've downloaded it, so I can remove the file.

http://64.72.236.146/softsqueeze-src-svn12563.zip

Ralphy

[Mark Lanctot]

Hi all,

I have just uploaded the linux-x86 binary on sourceforge, as version 0.7.

Working fine on Ubuntu 7.04 64-bit here! Thanks Dominique!

[Dominique]

You're welcome Mark!

I'm considering adding another behavior change that would match my usage pattern. I want the ability for squeezeslave to:

1) tolerate being started even if slimserver is not alive and, in this case, wait for it to be started (instead of exiting).
2) tolerate slimserver to be stopped and, in this case, wait for it to be restarted.

I have implemented 1) yesterday evening, and 2) is a bit harder but feasible. This is all with the final goal of having an adequate slave playback engine on a PC that behaves like a service that you never have to restart. I was pointed towards "runit" (http://smarden.org/runit/), but I'm interested in a more integrated solution to minimize setup dependencies.

Anybody finds this feature interesting? How do people use squeezeslave? Is anything obvious missing for you?

Dominique

[JJZolx]

Anybody finds this feature interesting? How do people use squeezeslave? Is anything obvious missing for you?

Absolutely. Robustness is always a good thing. Like I mentioned previously, I run it as a Windows service, so it'd be great if it could survive a SlimServer restart. I connect from Squeezeslave/Softsqueeze over a VPN tunnel from work to home, and occasionally that tunnel gets closed and needs to be rebuilt. So being able to survive both a Slimserver restart and having the server "go away" for a time period are fairly important.

Can the Windows build currently be run natively as a Windows service? If not, can this capability be added? Right now I use srvany.exe to fake it.

[Dominique]

Hi Jim,

I don't know what is required from a program to make it "serviceable" under Windows. I know that in general, it needs to avoid reading from stdin, which is the problem I found and fixed originally.

It is also preferable for the program to have a way to exit cleanly so it can properly report itself to the server, for example, or log a clean termination to log files. I have also done this so that the SIGTERM signal can be used for this purpose. I believe there is more work that could be done in this respect: the squeezebox protocol has a BYE! message that supposedly tells slimserver of the shutdown. I may investigate this later on, as it may help slimserver remove the player from the list of available players instantly rather than after some period of time.

The next step towards "serviceability" is autonomy: a way for the program to monitor the server's availability, and it is what I intend to do now. Absence of manual intervention is a must.

Note that all these requirements are independent of any platform, and I believe squeezeslave should stay as independent as possible. There are external tools to turn a program into a service on most platforms (you told me of the Windows one, and I use the service-start-stop program that comes with Ubuntu).

Can you enumerate more platform-independent requirements that could be added to squeezeslave to make it more friendly to Windows service requirements? Note that I don't have access to a Windows machine, so whatever I do in squeeslave is proven to work on Linux (or Unices) but only *possibly* working on Windows (still waiting for someone on the forum to contribute a Windows binary to confirm it also works on Windows). Are there any drawbacks to the method you are using to make squeezeslave a service?

On the other hand, I would really like the platform-specific ways of starting/stopping the squeezeslave service to be generally available as well. The same way there are RPMs or debian packages for slimserver, it would be interesting to look at a user-friendly packaging that installs the program and its startup-scripts. I have zero experience in this field, but there's plenty of documentation for each platform.

OK, back to coding now.

Dominique

[oreillymj]

Dominique,

As mentioned there is a utility for windows called srvany which is a wrapper allows you to use pretty much anything that's executable on windows as a service.

If you want to write a "real" Windows service, then there are some simple requirements.
Any GUI for configuring the service should be external to the service itself. Services should not rely or wait on user interaction.
A service must handle 3 system event's i.e. Start, Stop & Pause. I believe this is done using callbacks.
A service should also regularly poll it's config file/registry keys for config changes and re-config itself on the fly.
Information messages and errors should be logged to the System event log, rather then displaying a dialog.

you should also code your .exe to support the /service parameter to register itself with the service control manager.

[oreillymj]

Ralphy,

Thanks, I grabbed a copy of the source.

Now let me see if I can remember how to set up a VC++ project.
It's about 5 years since I've wrested with VC++ 6.

[dr4stic]

Dominique wrote:
> You're welcome Mark!
>
> I'm considering adding another behavior change that would match my
> usage pattern. I want the ability for squeezeslave to:
>
> 1) tolerate being started even if slimserver is not alive and, in this
> case, wait for it to be started (instead of exiting).
> 2) tolerate slimserver to be stopped and, in this case, wait for it to
> be restarted.
>
> I have implemented 1) yesterday evening, and 2) is a bit harder but
> feasible. This is all with the final goal of having an adequate slave
> playback engine on a PC that behaves like a service that you never have
> to restart. I was pointed towards "runit" (http://smarden.org/runit/),
> but I'm interested in a more integrated solution to minimize setup
> dependencies.
>
> Anybody finds this feature interesting? How do people use
> squeezeslave? Is anything obvious missing for you?

I think it's a brilliant feature. You might want to consider adding it as an
option to the binary, maybe a -k for keepalive or some such (or a general -d
for daemon mode that does keepalive and doesn't touch stdin/err/out). This
way you wouldn't have to worry about any particular startup routine. You
could just distribute it with some sample dist-dependent rc.d init scripts
so that the daemon would start at system boot. Or, in the case of the
windows service, maybe have some windows dependent code that inserts itself
as a windows service on a windows machine.

I've been wanting a way to use a music plugin for mythtv that ISN'T
MythMusic and would be able to access my slimserver. I have two
squeezeboxes, but since they got rid of the wired version, and since they
stopped making them in Silver+Black which was my favorite, and the $50 extra
for wireless which I wouldn't use would kill me... I'm not looking for a
third squeezebox. If I could run squeezeslave at system boot and just open
MythWeb to the slimfx interface, I would be quite happy. And with php being
the only "language" I really know, I might even write a php-gtk frontend to
the CLI interface to make things easier and prettier.

I think your work is great! Thanks for it, seriously. :-)
-peace

[djh]

Thank you for the patches Dominique, I am really keen on squeezeslave as I have a particular use for it.

I run squeezeslave on a Fedora Linux host (the same as Slimserver runs on) and output audio via the onboard sound card to a small FM transmitter, so I can listen to music on any radio in the house. I keep squeezeslave synchronised to a Squeezebox which I use as a front-end to control the music selection.

This setup works well and the audio is surprisingly well synchronised, however I do have a couple of issues which I am hoping you may be able to help me with.

The audio only plays when I specify the "-d slimproto" option. This is more of an annoyance than anything else as it produces unnecessary debug information (which I redirect to /dev/null).

I also experience the same problem with startup as you. I try to start squeezeslave via a startup script but I don't think it gives Slimserver enough time to start itself. Have you discovered a solution to this?

Thanks,
Dominic.

[Robert Jorgensen]

I am an obvious novice here, but I would very much like to set up a
slimserver and use something like squeezeslave to play suing aconvolver
plugin to doom room correction and x-overs.

Can squeezeslave be used with convolver?

Greetings from Brussels

Robert

On 8/15/07, Dominique <
Dominique.2vdlez1187212501 (AT) no-mx (DOT) forums.slimdevices.com> wrote:
>
>
> You're welcome Mark!
>
> I'm considering adding another behavior change that would match my
> usage pattern. I want the ability for squeezeslave to:
>
> 1) tolerate being started even if slimserver is not alive and, in this
> case, wait for it to be started (instead of exiting).
> 2) tolerate slimserver to be stopped and, in this case, wait for it to
> be restarted.
>
> I have implemented 1) yesterday evening, and 2) is a bit harder but
> feasible. This is all with the final goal of having an adequate slave
> playback engine on a PC that behaves like a service that you never have
> to restart. I was pointed towards "runit" (http://smarden.org/runit/),
> but I'm interested in a more integrated solution to minimize setup
> dependencies.
>
> Anybody finds this feature interesting? How do people use
> squeezeslave? Is anything obvious missing for you?
>
> Dominique
>
>
> --
> Dominique
> ------------------------------------------------------------------------
> Dominique's Profile: http://forums.slimdevices.com/member.php?userid=12691
> View this thread: http://forums.slimdevices.com/showthread.php?t=37460
>
>

[inguz]

I am an obvious novice here, but I would very much like to set up a slimserver and use something like squeezeslave to play suing aconvolver plugin to doom room correction and x-overs.

Easiest way is probably to use my convolver plugin, http://inguzaudio.com/ - but you won't get active crossovers with this, it's two-channel all the way.

[Robert Jorgensen]

Well actually I think I was also aiming at a linux client and the using
Uli's acourate software to generate all the appropriate filters.

Robert

On 8/17/07, inguz <inguz.2vgnln1187355301 (AT) no-mx (DOT) forums.slimdevices.com>
wrote:
>
>
> Robert Jorgensen;221248 Wrote:
> > I am an obvious novice here, but I would very much like to set up a
> > slimserver and use something like squeezeslave to play suing
> > aconvolver plugin to doom room correction and x-overs.
>
> Easiest way is probably to use my convolver plugin,
> http://inguzaudio.com/ - but you won't get active crossovers with this,
> it's two-channel all the way.
>
>
> --
> inguz
> ------------------------------------------------------------------------
> inguz's Profile: http://forums.slimdevices.com/member.php?userid=1139
> View this thread: http://forums.slimdevices.com/showthread.php?t=37460
>
>

[Dominique]

The audio only plays when I specify the "-d slimproto" option. This is more of an annoyance than anything else as it produces unnecessary debug information (which I redirect to /dev/null).

Strange... I thought I had left the debug info out for the release version. Are you using the version from sourceforge or have you compiled it yourself? Normally, when debug-tracing plays a role in a multithreaded program working or not, this points to a race condition of some sort. Since you seem to have tracing on, can you figure out (with other tracing levels) what state is squeezeslave in when it "doesn't play"?

I also experience the same problem with startup as you. I try to start squeezeslave via a startup script but I don't think it gives Slimserver enough time to start itself. Have you discovered a solution to this?

Yep. I am currently working on a "-r/--retry" option that will cause squeezeslave to poll the slimserver presence (every 3 seconds works well, but I may make it configurable) until slimserver shows up. This part of my enhancement works well right now. I am also trying to yank in the tolerance to slimserver stop-restart and this proves more difficult.

I'm hoping to solve this over the week-end or early next week.

Dominique

[Dominique]

I think it's a brilliant feature. You might want to consider adding it as anoption to the binary, maybe a -k for keepalive or some such (or a general -dfor daemon mode that does keepalive and doesn't touch stdin/err/out). This way you wouldn't have to worry about any particular startup routine. You could just distribute it with some sample dist-dependent rc.d init scripts so that the daemon would start at system boot. Or, in the case of the windows service, maybe have some windows dependent code that inserts itself as a windows service on a windows machine.

As I explained a few minutes ago, I'm working on a -r/--retry option that will to just that. I'm using xubuntu, so I'll probably come up with a init script for ubuntu-compatible distributions. Not sure where to distribute this, though: slimdevices subversion and/or in the .tgz on sourceforge?


I've been wanting a way to use a music plugin for mythtv that ISN'T MythMusic and would be able to access my slimserver. I have two squeezeboxes, but since they got rid of the wired version, and since they stopped making them in Silver+Black which was my favorite, and the $50 extra for wireless which I wouldn't use would kill me... I'm not looking for a third squeezebox. If I could run squeezeslave at system boot and just open
MythWeb to the slimfx interface, I would be quite happy. And with php being the only "language" I really know, I might even write a php-gtk frontend to the CLI interface to make things easier and prettier.

You should be able to use squeezeslave this way when I'm done with my current work. As for pretty front end, I'm sticking to the web interface for now using a version of the Touch skin that I tweaked so it nicely fills a 17 inches 16:9 monitor in my living room. But it's still not a good replacement for a good remote-control-operated interface.

Thanks for your feedback!

Dominique

[dr4stic]

Dominique wrote:
> Kendrick Vargas;221203 Wrote:
>> I think it's a brilliant feature. You might want to consider adding it
>> as anoption to the binary, maybe a -k for keepalive or some such (or a
>> general -dfor daemon mode that does keepalive and doesn't touch
>> stdin/err/out). This way you wouldn't have to worry about any
>> particular startup routine. You could just distribute it with some
>> sample dist-dependent rc.d init scripts so that the daemon would start
>> at system boot. Or, in the case of the windows service, maybe have some
>> windows dependent code that inserts itself as a windows service on a
>> windows machine.
>
> As I explained a few minutes ago, I'm working on a -r/--retry option
> that will to just that. I'm using xubuntu, so I'll probably come up
> with a init script for ubuntu-compatible distributions. Not sure where
> to distribute this, though: slimdevices subversion and/or in the .tgz on
> sourceforge?

Normally what I've seen is that it's distributed as a folder in the source,
usually in a contrib folder. It'd probably be a good idea to keep that on
slim svn. Then if anyone builds binaries for a particular system they could
use redhat.init or xubuntu.init, or what have you. The package for that
native system would have the right init script. Anyone going from source
would know what they were doing anyways.
-peace

[Dominique]

Hi again,

I have just committed more of my squeezeslave work to the slimdevices svn repository. This time, as I had pointed out in my recent messages, I have worked on tolerance for broken connections.

Always in spirit of backwards compatibility, this feature has been implemented as a new option: -r/--retry. This option causes squeezeslave to:

. Wait for slimserver to be started if not present when squeezeslave starts. It does so by retrying the connection every 3 seconds. It used to just exit.
. Perform proper internal cleanup when slimserver drops the connection and goes back waiting for slimserver to come back up. It used to deadlock itself and never exit unless terminated with SIGTERM.

For proper daemonization, you must thus use -s/--signal (to control stopping via SIGTERM) and the new -r/--retry. This way, squeezeslave is one step closer to being a set-and-forget.

Note that I have not yet worked on a debian-compatible init script (my distribution being Xubuntu). It may come later and would be part of a more serious distribution process. However, I am perfectly happy with adding a "Squeeze Slave" entry in my Xubuntu "Autostarted Applications", which invokes squeezeslave --signal --retry.

I have added a linux binary download on sourceforge:

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494&release_id=532275

If you are able to contribute other binaries, I will upload them for you.

Enjoy,

Dominique

[ralphy]

Dominique,

I've managed to build a new squeezeslave 0.7.1 binary for Solaris 9 SPARC.

I had to change the two MSG_NOSIGNAL defines back to 0 as in 0.7.0, since Solaris doesn't define this flag for send/recv.

The new binary works, not sure what impact the change has on functionality though.

http://paddockd.freeshell.org/squeezeslave-0.7.1-sol9-sparc.tar.gz

I've included LICENSE.txt this time.

Ralphy.

[Dominique]

Hi ralphy,

Removing MSG_NOSIGNAL means that the process will receive a SIGPIPE signal whenever it sends data to a closed socket. Depending on when slimserver is closed, squeezeslave will be either reading from the socket, or writing to it. If it is reading, the close is flagged by having the recv system call return -1.

If it is writing, however, the process receives a SIGPIPE signal which causes the program to exit. Passing MSG_NOSIGNAL to the 'wirte' system call causes this behavior to be turned off and errors to be reported using a -1 return value, like the other errors. This was one of the first things I fixed to get more robustness.

I had not realized I had implemented this in a non-portable way. On solaris, the preferred way is to inhibit the SIGPIPE signal by installing a signal handler that does nothing (or maybe a null function pointer? I'll try this out later). So if you're in a hurry, you can just duplicate the way I install signal handlers in softsqueeze.c using the 'signal' system call and give it a dummy function.

The only thing I dislike about this approach is that technically, squeezeslave.c is a client of SlimProtoLib and by doing this, it is forced to perform setup that should be performed by the library. On the other hand, if the library were to do it, then it would have turned of SIGPIPE signal for the whole process and not just for the library, which makes it invasive in case other parts of your program require proper SIGPIPE receiving.

So if you have time for this, can you look into a better way to turn off SIGPIPE just for one file descriptor? Maybe somewhere in man page for setsockot, write or ioctl. If we have no luck, I'll just commit the changes I described above (tonight, though).

Dominique

[Dominique]

As a follow-up to my previous message: apart from having a per-socket way of turning off SIGPIPE, the cleanest way to disable a signal (SIGPIPE, in the example) is:

signal( SIGPIPE, SIG_IGN );

Dominique

[ralphy]

Dominique,

I'm in no hurry, I don't restart slimserver very often, as in almost never. If you decide to reimplement the handling of SIGPIPE in a more portable manner that's great. If not, a couple of #ifdef's should to the trick.

There's an RFE open in Solaris 10 to add a mechanism to disable generation of SIGPIPE on a per-socket, per-fd and per-send basis, but it currently is not implemented. The suggested work around is to temporarily set SIGPIPE to SIG_IGN before calling send and restore immediately afterwards.

Ralphy.

[Dominique]

Hi ralphy,

I was aware of this trick but, apart from adding more system calls, it still is not entirely satisfactory to me: signals and threads don't necessarily play nice together.

The effect of installing a signal handler in a multi-threaded process is, as the man page goes, "unspecified". In practice, the signal handlers are shared between all threads (so this will affect other threads, in a race-condition type of way) although each thread has its own signal mask. I had problems because of this, which is why I install the signal handlers while the threads have been started yet and the process still is single-threaded. This is also the reason I am using 'kill(getpid(),SIGCHLD)' instead of 'raise(SIGCHLD)' to send a signal that will unblock the pause() in the main thread.

Please correct me if I'm wrong... At this point, I'd lean more towards a permanent blocking of SIGCHILD with an appropriate FIXME, than using a method that may cause intermittent and hard to reproduce problems.

Dominique

[ralphy]

I like the current Linux implementation, it's clean.

That being said, is it supported in Windows sockets?

Perhaps permanently blocking SIGCHLD as you suggest is the better way to go if it's more likely to work with Windows and MacOS as well.

Ralphy.

[Dominique]

I like the current Linux implementation, it's clean.

That being said, is it supported in Windows sockets?

Perhaps permanently blocking SIGCHLD as you suggest is the better way to go if it's more likely to work with Windows and MacOS as well.

Ralphy.

No idea about Windows. For MacOS, I know it has a parameter to setsockopt: SO_NOSIGPIPE. This is also a nice way of doing it, although equally non-portable.

Anyways, if nobody objects, I'll go with signal(SIGPIPE, SIG_IGN) and we'll let our Windows users comment on how the approach works for them (anyone here has any Windows binary for squeezeslave?).

Dominique

[Dominique]

Hi ralphy,

I have just committed the fix we discussed earlier. I have attempted to preserve the best behavior for each of the platforms I know (or could read about).

1. Linux platforms will use MSG_NOSIGNAL
2. BSD variants will use setsockopt with SO_NOSIGPIPE
3. The rest will use a global SIG_IGN for SIGPIPE.

I was able to test options 1 and 3 with success. Can I count on you to report your experience with option 2?

The svn version of my changes is 12678.

Dominique

[Heimiko]

Hello all SqueezeSlave devs.

Noticed the 0.7.1 binaries are now available on SourceForge. However, a win32 binary is missing, any chance one of you guys can compile it?

[Smiley Dan]

I've been wanting a way to use a music plugin for mythtv that ISN'T
MythMusic [snip]
I'm in the same boat. I had toyed with mpd running against stream.mp3 but a proper, native slim daemon was always going to be the best bet.

Perfection would involve a full QT plugin for Myth, for which one has already been discussed (http://forums.slimdevices.com/showthread.php?t=35306). MythBrowser may help in the meantime...

This is all great work.

[ralphy]

Dominique,

The new version does retry connecting to slimserver until I start it and I can then play music.

After I stopped the player, and stopped/started slimserver the squeezeslave instance is no longer seen by slimserver.

Here's the sequence of events and associated output.

# Starting squeezeslave with slimserver stopped.

$ squeezeslave-0.7.2 -s -r --mac "8:0:20:f0:da:c9" ralphydt
Output devices:
0: SUNW,CS4231
Error connecting to 10.16.0.247:3483
Error connecting to 10.16.0.247:3483
Error connecting to 10.16.0.247:3483
Error connecting to 10.16.0.247:3483
Error connecting to 10.16.0.247:3483
Error connecting to 10.16.0.247:3483
Error connecting to 10.16.0.247:3483
Error connecting to 10.16.0.247:3483

# Started slimserver v6.3.1, haven't upgraded yet.
# Started playing an mp3 and listened for ~2min.
# Stopped the player and stopped slimserver, get this from squeezeslave;

Error in recv: Connection reset by peer

# Restarted slimserver, but player is not found.
# Squeezeslave never produced any other messages after that.
# Killed squeezeslave several times and restarted, still no joy.
# Killed squeezeslave and started debug version.

$ squeezeslave-0.7.2-debug -d slimproto -s -r --mac "8:0:20:f0:da:c9" ralphydt
Output devices:
0: SUNW,CS4231
slimproto_connect(ralphydt, 3483)
proto state=1
slimproto_stat
code=stat
decoder_buffer_size=1048576
decoder_buffer_fullness=0
bytes_rx=0
output_buffer_size=3528000
output_buffer_fullness=0
elapsed_seconds=0
slimproto_send: cmd=STAT len=41
slimproto_stat
code=stat
decoder_buffer_size=1048576
decoder_buffer_fullness=0
bytes_rx=0
output_buffer_size=3528000
output_buffer_fullness=0
elapsed_seconds=0
slimproto_send: cmd=STAT len=41

# slimproto_stat continues repeatedly.


I managed to get slimserver to recognize the squeezeslave player 1 time in about 20 kills/restarts. I killed it too quick the one time it was recognized and haven't been able to get it to connect since. Even tried removing the player manually from slimserver.conf. I'll reboot the windows machine running slimserver when I can and try again.

Ralphy.

[Dominique]

Have you tried stopping slimserver *while* playing? I must admit I haven't tried stopping slimserver while not playing in a long time.

Can you confirm that, on your platform, slimproto_configure_socket uses the setsockopt approach? If so, can you force it to use the signal(SIGPIPE, SIG_IGN) approach and see if this works better?

It could also be that there are differences between 6.3.x and 6.5.x servers in the way they connect. If this is the problem, I could add server-version detection in squeezeslave to at least warn that the server stop-restart does not work. I'd suggest you upgrade the server, but if you can wait a bit (and have some time to devote to this), I'd like to find out what the problem really is before you change your setup. So here's the plan:

. I check on my system if server stop-restart while player does *not* play works fine. I'll report on this tonight, with a fix if needed.
. You change slimproto_configure_socket so it sets up the SIGPIPE ignore. If this works, then this will "disqualify" my attempt at using SO_NOSIGPIPE and I'll remove it. If this doesn't work and the server stop-start-while-not-playing does work on my system, then you'll need to upgrade (if you're interested in this aspect of the feature, of course).

Should we carry this discussion privately or is it of any interest to the forum?

Dominique

[ralphy]

Going private until we work this out.

Ralphy

[thorium]

I fixed a few problems I ran into when compiling the newest sources.

First, squeezeslave wouldn't compile with flac-1.2.0 so I added some porting code to support both the legacy API (<flac-1.1.3) and the newer API (>=flac-1.1.3).

Also, slimaudio_http.c wouldn't compile using gcc-4.1.2 with the debug flag set.

Finally, I noticed that squeezeslave is still using portaudio_v18. It would be nice to use the newer development portaudio_v19 builds so squeezeslave could support native sound output on most platforms. On Linux, getting squeezeslave to use ALSA natively would be especially nice, since then dmix could be used to allow other programs to output sound at the same time as squeezeslave.

Another good thing would be to allow linking to an external portaudio library, but that would probably require cleaning up the build system a bit.

[Dominique]

Hi thorium,

Thanks a lot for your patches, I'll apply them tonight and commit them to subversion. I have just installed flac 1.2.0 on my system but had not yet tried to use squeezeslave with it (just tried it for encoding).

About portaudio, I'll have to chat with Richard Titmuss because I know there is a plan is to move to SDL (or you can ask him if you want, I don't have any kind of authority over this anyways!).

About external linking, my take is that it would be nice to have as little static linking at all. Right now, there's flac, vorbis, vorbisfile, ogg, portaudio, portmixer... But then we'd need a proper dependency management system, i.e. platform-specific packages.

I also have a few things I plan to add: clearer debug messages and keep-alive timeout control. Also the -r/--retry option is not entirely bug-free: sometimes, right after booting, I have to stop/restart playback before I can actually hear something.

Anyways, thanks for your work!

Dominique

[Dominique]

Hi again,

thorium's changes were committed on slimdevices subersion repository, at 12747. I've tried squeezeslave with flac 1.2.0 and it works fine. The current squeezeslave binary for Linux is compiled with flac 1.1.2 (not sure about sparc: ralphy?).

Anyone feels I should upload my binary with flac 1.2.0? I'm aware of decoding performance improvements between 1.1.2 and 1.2 but I'm not sure they're meaningful for squeezeslave. Plus I don't want to pepper the sourceforge repository with nano-increments. Opinions?

Dominique

[thorium]

About portaudio, I'll have to chat with Richard Titmuss because I know there is a plan is to move to SDL (or you can ask him if you want, I don't have any kind of authority over this anyways!).

That sounds fine since anything that supports native ALSA is good enough for me (I want dmix support).

About external linking, my take is that it would be nice to have as little static linking at all. Right now, there's flac, vorbis, vorbisfile, ogg, portaudio, portmixer... But then we'd need a proper dependency management system, i.e. platform-specific packages.

Have you ever worked with cmake? I have found it a lot easier to support cross-platform builds with its scripts compared to the likes of autoconf/automake. Perhaps we could begin to fashion a better build system using it.

Also I was wondering, are there any working patches floating around for daemon support? I found a few old, hackish ones, but was hoping something better existed.

Finally, a possible bug I have been running into relates to connecting to internet radio streams. I can't get squeezeslave to play any internet radio streams unless I turn on the proxying option in the slimserver settings. When I do, a few streams work fine, others work and then start crackling like the audio sync is off, and some refuse to work at all and often throw decoding errors. Has anyone run into these issues?

Tim

[ralphy]

Hi again,

... The current squeezeslave binary for Linux is compiled with flac 1.1.2 (not sure about sparc: ralphy?).

The solaris sparc binaries are using flac 1.1.2, portaudio v18.1, libmad 0.15.1b, libogg 1.1.3 and libvorbis 1.1.2.

Anyone feels I should upload my binary with flac 1.2.0? I'm aware of decoding performance improvements between 1.1.2 and 1.2 but I'm not sure they're meaningful for squeezeslave. Plus I don't want to pepper the sourceforge repository with nano-increments. Opinions?

Dominique

Perhaps we should keep with the current support library versions until we get the Windows port running and iron out the few outstanding bugs we've encountered. Then make the move, flac 1.2, portaudio v19 and the others if need be.

I think trying to maintaining dynamically linked squeezeslave binaries is something we should avoid for now. The small amount of additional memory used far outweighs the additonal headache of trying to troubleshoot library version incompatabilities.

I'm hoping to get a chance to attempt a Windows build in the next couple days, time permitting.

Ralphy.

[Dominique]

Hi Tim,

Have you ever worked with cmake? I have found it a lot easier to support cross-platform builds with its scripts compared to the likes of autoconf/automake. Perhaps we could begin to fashion a better build system using it.

No I have not. I'm interested in a better build and distribution system but for now I'm more interested in stability and missing features. But I'm just stating my interests here: feel free to ask Richard Titmuss (who I consider has authority on this project) what his thoughts are regarding squeezeslave's build system.

Also I was wondering, are there any working patches floating around for daemon support? I found a few old, hackish ones, but was hoping something better existed.

As far as I am concerned, on the Unix side, I've made changes that make me believe daemon support is here:

-s/--signal causes squeezeslave to be stoppable with SIGTERM instead of using stdin (which was the big culprit for non-daemonizability, if there's such a word).
-r/--retry causes squeezeslave to tolerate slimserver to go down whenever it wants.

There could be better tracing/logging (I'll probably work on it), but for the rest, it's just a matter of how you integrate it with your boot system. It was suggested that we supply such scripts in a "contrib" directory of squeezeslave for various platforms, which I think is a nice idea. For my part, Xubuntu has a "Autostarted Applications" feature that works perfectly well for me: as soon as my session is started, squeezeslave is running.

Finally, a possible bug I have been running into relates to connecting to internet radio streams. I can't get squeezeslave to play any internet radio streams unless I turn on the proxying option in the slimserver settings. When I do, a few streams work fine, others work and then start crackling like the audio sync is off, and some refuse to work at all and often throw decoding errors. Has anyone run into these issues?

Tim

Haven't tried radio much. Anything more precise? Which stations work, which don't, correlation between format used and stability? Did you set a high-enough value for "prebuffering" for this player? Come to think of it, we should check if the client has anything to do to properly "support" this pre-buffering.

Dominique

[inguz]

Hoping not to derail this thread with a feature request. (I'm happy to code on this, too). Not urgent, but something I want to play with soonish.

What would it take to get multichannel output from Squeezeslave?

I have a few use cases:
- Creating a center channel signal from a stereo stream;
- Multi-amping with active crossovers;
- Surround processing (of various sorts, whether synthetic ambience reverb or Ambisonic).

In these cases I'd like my DSP (in the transcode pipeline) to do the appropriate processing, and output multichannel WAV or multichannel FLAC; then for squeezeslave to wire those output channels to various outputs on my audio card. But this would also need for Squeezeslave clients to be identifiable (from plugin perl) as having a particular number of channels (>=2), and/or a particular channel mapping.

[Dominique]

The solaris sparc binaries are using flac 1.1.2, portaudio v18.1, libmad 0.15.1b, libogg 1.1.3 and libvorbis 1.1.2.

Thanks for the info.

Perhaps we should keep with the current support library versions until we get the Windows port running and iron out the few outstanding bugs we've encountered. Then make the move, flac 1.2, portaudio v19 and the others if need be.

I agree.

I think trying to maintaining dynamically linked squeezeslave binaries is something we should avoid for now. The small amount of additional memory used far outweighs the additonal headache of trying to troubleshoot library version incompatabilities.

Where I see an interest is more in letting people upgrade to the latest compatible libs without us having to produce a new binary every time libTransmogrify fixes one bug, or without forcing them to recompile a new squeezeslave on their own. But this just the long term purist view. For now, I also believe it is more reasonable to spend time fixing bugs or implement features (like this multichannel idea from inguz).

Dominique

[thorium]

Is there a reason the PCM output volume always has to be set to max when new songs are played?

Personally, I don't think this should happen. I find it annoying for squeezeslave to set the volume level by itself. Can someone explain what this is good for?

Anyway, see the attached patch for a hackish fix and to find the code I am talking about.

[rtitmuss]

Finally, I noticed that squeezeslave is still using portaudio_v18. It would be nice to use the newer development portaudio_v19 builds so squeezeslave could support native sound output on most platforms. On Linux, getting squeezeslave to use ALSA natively would be especially nice, since then dmix could be used to allow other programs to output sound at the same time as squeezeslave.

As Dominique said the plan is to move to use SDL for the audio output replacing the portaudio library. This will allow squeezeslave (or a modified version of it) to be integrated into the Jive application.

Have you ever worked with cmake? I have found it a lot easier to support cross-platform builds with its scripts compared to the likes of autoconf/automake. Perhaps we could begin to fashion a better build system using it.

Also for compatibility with Jive the build system will be moving to autoconf/automake.

As Dean mentioned our intention is to replace Softsqueeze using a combined Jive/squeezeslave application (licensed under the Logitech Public Source License). It is going to be a while before I can start looking at this, and any assistance is welcome.

Cheers,
Richard

[Dominique]

Is there a reason the PCM output volume always has to be set to max when new songs are played?

Personally, I don't think this should happen. I find it annoying for squeezeslave to set the volume level by itself. Can someone explain what this is good for?

Anyway, see the attached patch for a hackish fix and to find the code I am talking about.

Hi thorium,

Thanks for your patch, I'll look at it tonight and possibly integrate it if I have time. Volume adjustment is something I had not have a chance to play with yet: my audio driver does not let me adjust the volume on the optical outputs...

As for multi-channel support, I've looked at the FLAC decoding, and it will only take the 16 uppermost bits of the first 2 channels of the decoded stream. I have not tried this, but it looks like it will at least not crash on streams with more than 2 channels (haven't looked at the other decoders). For the rest, there's a strong assumption of 16-bits stereo 44100Hz (mono is simply repeated on both channels).

It should be feasible to have the decoder instruct the output thread of its format requirements, but I see nothing of this sort for now. This should be considered during the port to SDL.

Dominique

[Dominique]

Hi all,

ralphy has been kind enough to produce a windows binary for squeezeslave 0.7. You can find it on sourceforge:

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494&release_id=532275

Note this is not the latest version available, we'll work out a portability issue and report back here as soon as possible. At least, windows users can now use squeezeslave with slimserver version 6.5.x.

Enjoy, and again many thanks to ralphy,

Dominique

[Dominique]

Is there a reason the PCM output volume always has to be set to max when new songs are played?

Hi thorium,

I have just looked at your patch and realized that you are disabling the support for replay gain. Replay gain is a way for slimserver to normalize the loudness of your tracks using tags that are embedded in your files. It sends an appropriate volume change command to the player when starting the playback of each file. You can read about it here:

http://www.replaygain.org

and here:

http://wiki.slimdevices.com/index.cgi?AutomaticVolumeAdjustment

(and on lots of other places on the wiki and on the web)

Replay gain can be turned off for a given player from the slimserver web interface. It in the audio settings section of the player.

Now, I don't know what slimserver does if your files were encoded without replay gain information, but that's another question. Are you telling me that you receive volume changes even if replay gain is off?

A valid enhancement to the current behavior would be for squeezeslave to use these volume commands as a delta around the current volume. But then again, with SDL, I suppose squeezeslave will have its own entry in the "master mixer" and the absolute volume will become relative to that of the mixer...

Tell me if this makes sense. I cannot apply your patch as it is, since it disables a feature so we'll have to understand what's happening on your system.

Dominique

[awy]

Finally, a possible bug I have been running into relates to connecting to internet radio streams. I can't get squeezeslave to play any internet radio streams unless I turn on the proxying option in the slimserver settings. When I do, a few streams work fine, others work and then start crackling like the audio sync is off, and some refuse to work at all and often throw decoding errors. Has anyone run into these issues?
Tim

Yes. The problem is that squeezeslave does not take any notice of the stream-server IP-address in the STRM-s command (although curiously, it takes notice of the port number) - there is a FIXME in the code. I have a patch (not to hand - I'll post it over the weekend) and it works ok for same stations.

There may well be a problem with the HTTP request that gets used for shoutcast, as it probably asks for embedded metadata and my guess (without checking) is that softsqueeze does not handle this.

I suspect that the problem with some stations may be that they use a frame rate other than 44100 - which is currently hard-wired into both squeezeslave and SoftSqueeze, but there could be other reasons too.

Alan.

[awy]

Here is the list of issues that I have identified with squeezeslave:

Frame-rate is hard-wired at 44100
Volume control does not work (on my Linux system)
Need to integrate (my) sync-management protocol changes
Remote streaming & meta-data
Define specific player-type for SlimProto and use with NoDisplay display-type in the server
device/channel selection - ability to select specific channel-pairs from card: e.g. hw:1.2

[thorium]

Now, I don't know what slimserver does if your files were encoded without replay gain information, but that's another question. Are you telling me that you receive volume changes even if replay gain is off?

I don't use replay gain information so whenever slimserver moves to another track, squeezeslave bumps up the PCM volume to 100%. The PCM volume is always increased to 100% no matter what level it was previously set at.

With cheap sound cards found in many onboard chipsets, this can distort output and really hurt the ears if headphones are being used.

Tell me if this makes sense. I cannot apply your patch as it is, since it disables a feature so we'll have to understand what's happening on your system.

Yeah, it makes sense. I didn't mean for my patch to be applied. It was just meant to show the code causing the problems for me.

However, if this situation occurs due to missing replay gain information I would classify it as a bug since I have replay gain disabled for all clients.

[thorium]

During more testing, squeezeslave always set PCM volume to 32%.

Relevant slimaudio debug output:
audg cmd 5100 0.316406
pcm volume 0.320000

Is there logic somewhere in the slimproto.c file that checks if the replay gain option is turned on for the client and sets the gain variables accordingly? I couldn't find any code performing that function.

[Dominique]

Hi thorium and others looking at the replay-gain problems,

I'm not aware of any other logic that what is done when receiving the audg command. I thought that it was entirely managed on the server-side, but I'll have to sit down and look at it (which awy seems to have done already). Possibly this week-end if I get a few hours.

awy, it'll be my pleasure to integrate your patch if you send it here over the week-end.

Dominique

[awy]

Here is the patch I promised.
Alan.

[awy]

Dominique, there is still a thread/timing race somewhere during startup. I have not managed to track this down yet as, inevitably, it never occurs when in a debugger, but I'll keep trying. I'm posting this in case you have an immediate idea. It looks like the code never makes it into proto_connect().
Alan.

[Dominique]

Dominique, there is still a thread/timing race somewhere during startup. I have not managed to track this down yet as, inevitably, it never occurs when in a debugger, but I'll keep trying. I'm posting this in case you have an immediate idea. It looks like the code never makes it into proto_connect().
Alan.

Hi Alan.

I also get this once in a while, but only when I've just rebooted; never when squeezeslave is started manually. This makes a good business case for me to implement proper logging: it's kinda hard to figure out anything with the current output.

I'll look at your patch later on today.

Dominique

[Dominique]

Here is the patch I promised.
Alan.

And here is the commit I promised:
'Committed revision 12840.'

I have some changes I want to commit, and I'll upload a new linux binary to sourceforge. How do people feel about updating the sourceforge binary for every bugfix? Should we wait for some more stabilization? Should we only keep the latest 0.7.x?

Dominique

[dr4stic]

Dominique wrote:
> awy;224347 Wrote:
>> Here is the patch I promised.
>> Alan.
>
> And here is the commit I promised:
> 'Committed revision 12840.'
>
> I have some changes I want to commit, and I'll upload a new linux
> binary to sourceforge. How do people feel about updating the
> sourceforge binary for every bugfix? Should we wait for some more
> stabilization? Should we only keep the latest 0.7.x?

Might be a good idea to just name the files with the revision number in
there, or a date. Something like 0.7-r12840. That way it'll be easier to
track which revisions of which versions people are using.
-peace

[Dominique]

During more testing, squeezeslave always set PCM volume to 32%.

Relevant slimaudio debug output:
audg cmd 5100 0.316406
pcm volume 0.320000

Is there logic somewhere in the slimproto.c file that checks if the replay gain option is turned on for the client and sets the gain variables accordingly? I couldn't find any code performing that function.

Hi thorium,

Just spent some time looking at the volume behavior. For each new song, slimserver sends the gain value that is set *from the player or the web interface*. The current implementation of volume change seems to be changing the volume on the device (rather than, for example, processing a volume change in software). So if you want your volume changes to survive the end of the current song, you have to do them through the web interface.

I can understand this is an annoying behavior although it is kinda logical: squeezeslave takes ownership of the output device and slimserver tells it what volume to set.

I'm not sure how to address this:
1. Add an option to squeezeslve: -v/--volume [on|off]
2. Refine the volume changes so it considers 100% to be the device's volume when squeezeslave started.
3. See if we can rework Portmixer's usage to address another mixer, assuming it is possible to use a dmix-like approach with the current version (hope SDL will make this possible).

1 seems the most direct and reasonable, but let's discuss this.

Dominique

[ralphy]

Dominique wrote:

1 seems the most direct and reasonable, but let's discuss this.

Dominique

I'd like to add my vote for option 1.

The Solaris binaries currently use the null mixer, as portmixer doesn't support the Solaris mixer. It's been on my list to add for some time, however, as the plan seems to be a move to SDL, maybe I can scratch that one off.

I dislike the volume change at each song start so much, that I even build my own Linux binary with no mixer code. You can then use your favourite mixer program to adjust the volume. I always use the volume up/down and mute keys on the Sun keyboard anyway.

dr4stic wrote:

Might be a good idea to just name the files with the revision number in
there, or a date. Something like 0.7-r12840. That way it'll be easier to
track which revisions of which versions people are using.

I think this is a good idea as well, until things stabilize. I'm finding it hard to keep which version it is I'm running straight now; between Solaris, Linux and Windows.

dominique wrote:
I also get this once in a while, but only when I've just rebooted; never when squeezeslave is started manually.


I've been seeing the race condition on Solaris regularly and last week it happened a couple times on my linux system as well, both of which only get rebooted when the UPS says "time to shutdown". Unfortunately, I haven't had time to look into it in more detail.

Well, back to the office move.....

Ralphy.

[Dominique]

I'd like to add my vote for option 1.

Personnally, replay-gain is a feature I want as I experience significant loudness differences across albums. I'll see how far I can go with the -v/--volume option. Maybe 'on', 'off', and 'rel', 'rel' meaning gain relative to what it was when squeezeslave started. I'll also see if it's possible to distinguish between volume changes due to user interaction and volume changes due to replay-gain.

About the version label on sourceforge: I don't mind switching to this convention, but to me the proper fix would include a new -V/--version option.

About the race condition: I have fixed something in my 'development' version, but this was a problem in code I had written and that is not yet committed. Next time it happens, don't forget you can attach gdb to a running process to see where all threads are.


Dominique

[awy]

Well I found out, at least in part, why volume-control does not work at all in my Linux environment. Px_OpenMixer(), called in slimaudio_output.c, returns null. I have not yet investigated why.

On the subject of my patch to support direct streaming. I guess that it is better than the current situation, but only marginally. It will perform poorly with any Shoutcast stream that supplies metadata as it does not have the code to extract said metadata and the resulting MP3 frames are therefore corrupt (The HTTP request supplied by the server includes the Icy-MetaData header to request inline metadata).

Overall, I think that squeezeslave is much more like a SqueezeBox(1) than an SB2/3, which is the base player-type that it gets handled as. I'll knock up a suitable Player module just as soon as I can get my SS7 runtime environment up. I think that, in this module, I will just disable all support for direct-streaming; for the moment at least, I think that one is unlikely to be running squeezeslave without a local SS, and hence there is no real advantage in direct streaming.

Alan.

[Dominique]

Well I found out, at least in part, why volume-control does not work at all in my Linux environment. Px_OpenMixer(), called in slimaudio_output.c, returns null. I have not yet investigated why.

I keep saying it: tracing feedback should report things like this. Anyways, I'll work on the proposed -v/--volume option tonight. It seems clear we want a on/off control for gain changes, but beyond this I'm waiting for suggestions. I haven't found a way to determine what part of the gain change is due to user interacting with the interface and what part is due to the replay-gain. One feature I have noticed, though, is "preamp volume". This is another volume control that slimserver uses to control the preamp on players that have one. The server-side player plugin for squeezeslave could use the preamp gain for volume changes and volume for replay-gain changes. Anyways, I really need to look more at the code.

On the subject of my patch to support direct streaming. I guess that it is better than the current situation, but only marginally. It will perform poorly with any Shoutcast stream that supplies metadata as it does not have the code to extract said metadata and the resulting MP3 frames are therefore corrupt (The HTTP request supplied by the server includes the Icy-MetaData header to request inline metadata).

Can't we configure the decoder so it ignores this metadata?

Overall, I think that squeezeslave is much more like a SqueezeBox(1) than an SB2/3, which is the base player-type that it gets handled as. I'll knock up a suitable Player module just as soon as I can get my SS7 runtime environment up. I think that, in this module, I will just disable all support for direct-streaming; for the moment at least, I think that one is unlikely to be running squeezeslave without a local SS, and hence there is no real advantage in direct streaming.

Alan.

Can't challenge you on this: my squeezeslave usage is limited to running on the same machine as the server for now anyways. Someday, I'll want squeezeslave to be a standalone squeezenetwork client, but this day is far away.

I have also looked at the server-side player support. I really find it's too bad that Slimproto.pm has to know in advance of all the possible player types. It kinda breaks the player-module encapsulation... Why doesn't each player "type" register its id along with a callback to create an instance of itself? I may experiment with this if I feel like learning Perl properly...

Dominique

[Dominique]

Hi all,

I've just committed my latest changes to subversion, version 12903. From the sourceforge release notes:

. Option -r/--retry now accepts a parameter specifying the retry interval.
. New option -k/--keepalive lets specify the keepalive interval, which now defaults to 10s rather than 5s
. Auto-detection of slimserver version to turn off keepalive on pre-6.5.x versions.
. New option -V/--version.
. Fixed a deadlock happening during disconnection/failed connection.

The linux binary is at the usual place:

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494&release_id=532275

Following a recent suggestion, I've added the subversion version number to the filename for less confusion. The newest linux binary is thus named squeezeslave-0.7.2-linux-i386-svn12903.tgz.

Other binaries welcome: just post the url to your binaries to this thread and I will upload them to sourceforge.

Dominique

[sandos]

I also have trouble with the volume in squeezeslave under linux. On both my Ubuntu machines the volume seems to be set at 100% all the time, it ignores the setting in the slimserver web gui. Not being able to locally change the volume is fine with me though!

[thorium]

I'm not sure how to address this:
1. Add an option to squeezeslve: -v/--volume [on|off]
2. Refine the volume changes so it considers 100% to be the device's volume when squeezeslave started.
3. See if we can rework Portmixer's usage to address another mixer, assuming it is possible to use a dmix-like approach with the current version (hope SDL will make this possible).

1 seems the most direct and reasonable, but let's discuss this.


I also think option 1 seems like a decent solution for now.

[Dominique]

Hi all,

I have just committed version 12985 to subversion, which implements the discussed option to disable volume changes from slimserver. I've updated the doc as usual, so squeezeslave --help will explain the details.

The linux binary is right here:

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494&release_id=532275

Usual binary contributors act quick if you want me to upload to sourceforge: I'll go dark from September 13th to October 2nd.

Dominique

[awy]

Dominique,

I have started working on the enhancements to support sync-maintenance and the other protocol changes incorporated with SB2+ firmware 82. In doing this I am also tackling some of the other problems with the software, especially with respect to the (correct) implementation of various protocol and state-change features.

This includes handling different sample rates by delaying the call to Pa_OpenStream until entering the PLAYING state, and closing the stream when entering the STOPPED state.

I have come to the firm conclusion that the attempt to support direct streaming was a mistake as too much other related functionality is missing from squeezeslave. I'll work on a server patch that defines a specific player type for squeezeslave with the appropriate capabilities. I take your point about the server-side Player module - I am considering the possibility of a comprehensive clean-up or even re-architecture for this.

It makes sense to coordinate our work, probably outside the forum. I have sent you PM with my email address.

Alan.

[ralphy]

Hi all,

I have just committed version 12985 to subversion, which implements the discussed option to disable volume changes from slimserver. I've updated the doc as usual, so squeezeslave --help will explain the details.

The linux binary is right here:

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494&release_id=532275

Usual binary contributors act quick if you want me to upload to sourceforge: I'll go dark from September 13th to October 2nd.

Dominique

Dominique has uploaded solaris 9/10 SPARC and Solaris 10 x86 squeezeslave binaries to sourceforge. Both are available at the URL listed above.

Ralphy.

[Roger the Shrubber]

I am trying to run SqueezeSlave on Suse 9.3. I get "/lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /usr/local/slimserver/squeezeslave/squeezeslave)"

I am a total linux newbie, so I tried updating through Yast but there I only see glibc 2.3.4 listed.

Suggestions anyone?

[awy]

there is still a thread/timing race somewhere during startup. ... It looks like the code never makes it into proto_connect().


I tracked this down and checked in a fix yesterday. The problem was that the main thread could call slimproto_connect() before the proto_thread, fired up in slimproto_init(), had started and initialized the state.

Alan.

[ralphy]

I tracked this down and checked in a fix yesterday. The problem was that the main thread could call slimproto_connect() before the proto_thread, fired up in slimproto_init(), had started and initialized the state.

Alan.

That's great Alan, Thanks.

Your change fixed the constant problem I've been having with the Solaris versions. I no longer have to start squeezeslave 7 or 8 times before getting it to connect to slimserver. Run once, use a lot!

Ralphy.

[ericj]

Following this with interest, but noticed there is not a mac binary. Would one be possible/advisable?
Thanks so much for this work. I like the squeezeslave concept....

[Dominique]

Following this with interest, but noticed there is not a mac binary. Would one be possible/advisable?

Hi Eric,

squeezeslave can be compiled on OSX. Versions 0.2 to 0.6 all had a OSX binary, as you can see here, on the binary download page on sourceforge:

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494

It's just that nobody has yet contributed a OSX binary. If you are in a position to produce such a binary from the sources, just post a message to this board with an address to your binary and I will add it to sourceforge.

Here is the link to the relevant directory inside the subversion repository:

http://svn.slimdevices.com/trunk/softsqueeze/SlimProtoLib/

Dominique

[Dominique]

I am trying to run SqueezeSlave on Suse 9.3. I get "/lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /usr/local/slimserver/squeezeslave/squeezeslave)"

I am a total linux newbie, so I tried updating through Yast but there I only see glibc 2.3.4 listed.

Suggestions anyone?

Hi Roger,

Sorry for the long delay, I was away for some time.

You are getting this error because your version of glibc is too old for the squeezeslave executable. Upgrading glibc with Yast will probably be of no use because the newer glibc has not been backported to Suse 9.3. You would have more luck with a contemporary version of Suse (10.2, if I Googled correctly).

Now, you say you are new to Linux so you may not feel like upgrading your distribution (although if you did, this would solve your problem). Another option is to compile your own squeezeslave executable. This is not difficult but not exactly a beginner's task. If you know your way in terms of C programming and subversion (the source control tool used for squeezebox-related code), this is far less intrusive as you won't have to touch the OS.

Just to add one trick to your diagnostic procedure, a good way to know what ABI (Application Binary Interface) your libc offers (i.e. what version of the GLIBC binary interface), you can use 'objdump -x /lib/tls/libc.so.6' on the command line. The "Version definitions" section will enumerate all supplied ABIS, which will include many versions of GLIBC. Mine has GLIBC_2.0, 2.1, 2.1.1, and so on, up to 2.5. To know what ABIs a program or library *requires*, in our case squeezeslave, you can use ldd -v ...bin/squeezeslave.

There's a lot to be said about dependencies and dynamic libraries on Linux, but I'll let you do your own reading if you want to learn more about this. Don't hesitate to come back here if you have specific questions on your way to compiling squeezeslave. I cannot offer any Suse support, though: I have never used this distribution.

Dominique

[bhaagensen]

Hi, just want to say thanks for reviving squeezeslave. It's wickedly nice because:

- It's very lightweight and seem to implement (the relevant parts) of slimproto. Hence it works significantly better then using stream.mp3.

- Using alsa-oss I can finally have the player always running without blocking the sounddevice. I, at least, have never managed to get software muxing working with SoftSqueeze.

- and it works with the squeezecenter pre-alpha.

Since alot seems to wants more, I'll allow myself to propose a couple of feature requests.

1. Keyboard shortcuts for play, pause, next, previous, vol_{up|down}. UI-wise I imagine something in the style of mplayer, i.e. running in the foreground in a terminal

2. Native ALSA on supported platforms.

Btw. I can't seem to locate the svn, or is it cvs, url. I'd be interested in having a look if possible.

Thanks,
Regards Bjørn

[Philip Meyer]

>1. Keyboard shortcuts for play, pause, next, previous, vol_{up|down}.
>UI-wise I imagine something in the style of mplayer, i.e. running in
>the foreground in a terminal
Wouldn't that defeat the purpose of it? It's meant to be used in the background. If you want play, pause, etc, use the WebUI, or use SoftSqueeze instead.

Phil

[Dominique]

Hi, just want to say thanks for reviving squeezeslave. It's wickedly nice because:
[...]
- Using alsa-oss I can finally have the player always running without blocking the sounddevice. I, at least, have never managed to get software muxing working with SoftSqueeze.


Hi Bjørn,

Glad you also like squeezeslave! Would you mind posting some details about your alsa-oss setup? I find myself in the following situation and am wondering if what you describe can be the key. My situation is that my audio device is an optical output, for which the device provides no volume control. I am considering coding a --volume=sw (for software volume), but would rather not if this can be supplied by another (standard) part of the system.


Since alot seems to wants more, I'll allow myself to propose a couple of feature requests.

1. Keyboard shortcuts for play, pause, next, previous, vol_{up|down}. UI-wise I imagine something in the style of mplayer, i.e. running in the foreground in a terminal


As Philip mentions in his post, squeezeslave is probably better thought of as a daemon, which by definition is UI-less and provides no direct user interaction. On the other hand, I share your need for a way to bind system events (shortcuts, remote control) with commands that would control squeezeslave.

Personnally, I use squeezeslave on a machine that also runs a web browser as the front-end, in a kind of set-top context. So I'm torn between looking at a way to configure Firefox so it binds system events to certain buttons in a web page (possible?) and opening a named socket from squeezeslave so that command-line utilities can send it button presses to emulate a remote-control that would get relayed to SqueezeCenter (formerly known as slimserver).

Opinions anyone?


2. Native ALSA on supported platforms.


The audio device abstraction used by SlimProto is PortAudio v18, which uses oss. Version 19 seems to support alsa (I looked very briefly). However, last time I have heard, there was a concensus to change this library for SDL (Simple DirectMedia Layer). SDL seems to support ALSA, but I cannot be completely affirmative yet. All this to say that it doesn't look like it will be done soon. Can you explain what advantages you see? Maybe it'll motivate me or others to look more closely!


Btw. I can't seem to locate the svn, or is it cvs, url. I'd be interested in having a look if possible.

Thanks,
Regards Bjørn

Look at the link I supplied in my reply to Eric, on 2007-10-02 22:09, five posts ago.

Dominique

[hickinbottoms]

Isn't that what the CLI is for? Rather than opening a socket to
squeezeslave you could open a CLI socket to SqueezeCenter and control
the squeezeslave player from there. You can build whatever front-end you
want on that (I think there might be a few around already).

Would that meet the need (assuming you can write/get hold of) the CLI
front-end app?

Stuart

Dominique wrote:
> bhaagensen;233926 Wrote:
>
>> Hi, just want to say thanks for reviving squeezeslave. It's wickedly
>> nice because:
>> [...]
>> - Using alsa-oss I can finally have the player always running without
>> blocking the sounddevice. I, at least, have never managed to get
>> software muxing working with SoftSqueeze.
>>
>>
>
> Hi Bjørn,
>
> Glad you also like squeezeslave! Would you mind posting some details
> about your alsa-oss setup? I find myself in the following situation
> and am wondering if what you describe can be the key. My situation is
> that my audio device is an optical output, for which the device
> provides no volume control. I am considering coding a --volume=sw (for
> software volume), but would rather not if this can be supplied by
> another (standard) part of the system.
>
>
>> Since alot seems to wants more, I'll allow myself to propose a couple
>> of feature requests.
>>
>> 1. Keyboard shortcuts for play, pause, next, previous, vol_{up|down}.
>> UI-wise I imagine something in the style of mplayer, i.e. running in
>> the foreground in a terminal
>>
>>
>
> As Philip mentions in his post, squeezeslave is probably better thought
> of as a daemon, which by definition is UI-less and provides no direct
> user interaction. On the other hand, I share your need for a way to
> bind system events (shortcuts, remote control) with commands that would
> control squeezeslave.
>
> Personnally, I use squeezeslave on a machine that also runs a web
> browser as the front-end, in a kind of set-top context. So I'm torn
> between looking at a way to configure Firefox so it binds system events
> to certain buttons in a web page (possible?) and opening a named socket
> from squeezeslave so that command-line utilities can send it button
> presses to emulate a remote-control that would get relayed to
> SqueezeCenter (formerly known as slimserver).
>
> Opinions anyone?
>
>
>> 2. Native ALSA on supported platforms.
>>
>>
>
> The audio device abstraction used by SlimProto is PortAudio v18, which
> uses oss. Version 19 seems to support alsa (I looked very briefly).
> However, last time I have heard, there was a concensus to change this
> library for SDL (Simple DirectMedia Layer). SDL seems to support ALSA,
> but I cannot be completely affirmative yet. All this to say that it
> doesn't look like it will be done soon. Can you explain what
> advantages you see? Maybe it'll motivate me or others to look more
> closely!
>
>
>> Btw. I can't seem to locate the svn, or is it cvs, url. I'd be
>> interested in having a look if possible.
>>
>> Thanks,
>> Regards Bjørn
>>
>
> Look at the link I supplied in my reply to Eric, on 2007-10-02 22:09,
> five posts ago.
>
> Dominique
>
>
>
> ------------------------------------------------------------------------
>
>

[Dominique]

Isn't that what the CLI is for? Rather than opening a socket to
squeezeslave you could open a CLI socket to SqueezeCenter and control the squeezeslave player from there.

Hi Stuart,

Thanks for the suggestion, it would certainly work well for the scenario described by Bjorn. I was thinking of delegating this to squeezeslave simply because there is a prototype of button-relaying functionality in there (commented-out for now) that would be easy to adapt. But a separate program looks like a better design, I agree.

Dominique

[bhaagensen]

Hi,

sorry about the late answer. On Linux there is a tool in the lirc-package which can map remote control events to keystroke events which can be captured by applications. Personally I found this to be useful for basic playback control such as skipping to the next/previous track, volume and pausing. I never took the time to figure out how to do it with CLI since it is almost trivial to set up using lirc.

I'm also often not having a browser running (low RAM system), so Alt-Tab'ing and a single keypress would be vastly faster for me. I realize though that with plethora of different ways of controlling SC it might be uncalled for and that the functionality would be limited anyway (no library browsing). On the other hand think of the good old CD-player days. Most would have to get up to change CD, but the basic controls got you a long way.

Thanks Bjørn

[bhaagensen]

Hi,


Glad you also like squeezeslave! Would you mind posting some details about your alsa-oss setup? I find myself in the following situation and am wondering if what you describe can be the key. My situation is that my audio device is an optical output, for which the device provides no volume control. I am considering coding a --volume=sw (for software volume), but would rather not if this can be supplied by another (standard) part of the system.



I'm not really very familiar with this stuff, so this will all be quite vague.

I just apt-get'ed and it just worked. But I think the idea is that alsa has some plugins, in particular one for software muxing (dmix). So the wrapper just makes sure that the application does not use the device directly, but instead routes through alsa so that whatever processing alsa can do is made available. So I think this could be a solution for you if there was a plugin for digital volume control. But I don't know whether such plugins exists.

I know that the pulseaudio sound server can do much more advanced processing. It's a pretty advanced sound server, and it's even being discussed for inclusion in Gnome. But again the details are unknown to me.

As for ALSA vs. OSS the main selling point for me is the ability to have several audio streams running concurrently. OSS has also been deprecated for many years now.

Bjørn

[Dominique]

Hi all,

A while ago we had a discussion of how annoying and dangerous it can be when squeezeslave changes the output device's volume. At the time, I have implemented a -v/--volume <on|off> option to control this behavior.

But this wasn't enough for me because I still wanted UI volume controls and replay gain to be supported. I also found myself with an output device for which the driver offers no volume control.

The response to this is a new argument to -v/--volume: sw. When specifying --volume sw, the volume changes will be processed on the CPU. The volume changes are "ramped" from the old to new value to prevent glitches.

Now, we all know that applying volume changes in software means a loss of dynamic range. So typically you will not get the same audio quality than if you leave the computer's volume as high as possible and control the volume using your preamplifier's volume knob. This is therefore not the purist's approach but is for those who can tolerate audio signal modifications at the benefit of functionality.

You can find the linux binary here:

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494

Usual contributors can post the location of their binaries for other platforms and I will upload them to sourceforge.

Hope this is useful to you and helps protecting some ears and speakers!

Dominique

[djh]

Hi Dominique

I have successfully compiled and installed the latest squeezeslave 0.7.4 on a Fedora 7 server, but the player does not appear in the SlimServer list when I start the squeezeslave client.

If I turn on slimproto debugging then I see that a connection is made to the server, but then it just waits indefinitely:

proto state=1
Output devices:
0: /dev/dsp
slimproto_connect(127.0.0.1, 3483)
proto state=2
Connected to 127.0.0.1
proto state=3
slimproto_send: cmd=HELO len=10
slimproto_recv: cmd= len=2
slimproto_recv: cmd= len=2
slimproto_recv: cmd= len=2
slimproto_recv: cmd= len=2
...

I have an older version of squeezeslave (before many of your enhancements) which does still connect without problems.

Can I do anything to help debug this problem?

Thanks,
Dominic.

[awy]

What version SlimServer/SqueezeCenter are you using? The new version will only work with a 7.0 server, unless you use the --oldplayer/-O flag (check the command-line usage help).

[djh]

What version SlimServer/SqueezeCenter are you using? The new version will only work with a 7.0 server, unless you use the --oldplayer/-O flag (check the command-line usage help).

Thanks, that solved it!

I must have looked at the command line options a hundred times and never spotted that switch.

Dominic.

[djh]

I have found squeezeslave really useful, thank you to Dominique and Richard for their work on this application.

I use it to sync with my main Squeezebox and then output audio to a sound card which is connected to a low-power FM transmitter. This means I can use Squeezebox to control music to any FM capable device in my home.

All my music is encoded with Windows Media Audio, is there any chance of WMA support for squeezeslave?

Thanks,
Dominic.

[Dominique]

Hi Dominic,

Sorry for the long time to answer, I was away last week.

My music is encoded in flac so I don't really have a "motive" to go through this. A bit of search, however, revealed that there exists a tool called ffmpeg that can be used to decode wma into wav on the fly, which is supported by squeezeslave. The format conversion on the server-side also lets you convert from wav to any format (mp3 for lower bandwidth or flac for some bandwidth savings and no loss in quality). This is where I found the info:

http://forums.slimdevices.com/archive/index.php/t-9649.html

Now, if you have your audio files encoded in WMA, I suspect you are running on Windows. ffmpeg seems to also work on Windows. I just googled for "ffmpeg windows" and some results came back, but note that I have not personally used any of this. Note that you may have to compile your binaries yourself, but at this point I'm just guessing.

Hope this helps, and it would be useful if you could report your success (or problems) here.

Dominique

[ggalt]

Dominique and Alan:

First, thanks for all of the hard work on getting squeezeslave up and running again. It has significantly improved in the past few months.

However, I'm stuck on Internet radio. I'm using the latest from SVN, which has Alan's changes, but I either get nothing or the program aborts in slimaudio_buffer.c at line 214: assert( data ), when I try to get a station through my SlimServer software.

For those stations where it aborts (WAMU, WBUR, WGBH, WNYC and WHYY are the ones I've notice so far), it aborts with *data being NULL and data_len = 8184 in each case. I think this may be traced to Alan's idea that metadata is corrupting the stream, but I know next to nothing about how the data is handled, so I'm not really qualified to render an opinion.

I'm on Fedora Core 6 (x86_64) running SlimServer 6.5.0 (I know, I know, I should upgrade, but I installed from an experimental yum repo and now I can't seem to back out). FYI, I've used the --oldplayer switch when launching squeezeslave since I understand this is needed when using something prior to SqueezeCenter 7.0.

If you have any ideas, I'm happy to try to help out and track down this issue. If you think it is related to my out-of-date server, let me know. I'll also be working in the near future on cleaning this up.

Thanks,

George

[awy]

The problem with internet radio (not necessarily your problem - more-detailed investigations would be necessary to confirm that) is that squeezeslave is asked by the server to direct-stream it, which actually it does not really know how to do. That is why, with the 7.0 server, squeezeslave has its own player type so that the server has a more-acurate idea of the player's capabilities. The --oldplayer flag makes the server think it is controlling a SqueezeSoft which has more capabilities - generally ok for local files but not for internet radio.

Alan.

[ggalt]

Alan:

It seems that when you define the player as a "squeezeslave" the server does not send any visual messages (grfe, etc.). Is that correct and was this behavior intended?

The reason is that I'm using the squeezeslave code to build a more robust client (along the lines of a stripped down softsqueeze, but in C++). My client uses the display messages to replicate the squeezebox2/3 display. If this is the case, I might have to choose between supporting Internet radio and the display.

Thanks.

George

[awy]

That is right. Squeezeslave has no display so let's not waste time sending it graphics messages. It uses the NoDisplay display-type.

Alan.

[liam.whiteside]

Hi,

I've just read through this thread after being pointed at it by ralphy.

There seem to have been quite a few improvements made over the last few months, most notably the -r option.

Is anyone in a position to compile a windows binary of the 0.7.4 version? (or anything newer!)

Currently I'm having issues with neither SoftSqueeze or SqueezeSlave 0.7 quite doing everything I need.

Thanks

Liam

[ralphy]

Liam,

Unfortunately, the code changes added to support the additional features can't be compiled with cygwin and the direct sound support currently used in squeezeslave for windows. I only built the 0.7.0 windows version so windows users could upgrade from slimserver 6.3.1. I built 0.7.4 for windows several months back, but the resulting binary uses 100% cpu and doesn't play any audio. As I'm a unix guy I don't know enough about the win32 API, cygwin and directx sdk to make the necessary changes and no one else has stepped up to build the latest code tree for Windows.

Ralphy.

[liam.whiteside]

Oh well. Unfortunately my C programming skills are very limited - one day I must learn... (but I think it's going to take a bit of work to progress from VB6 and 'Hello World' in C to being able to help with this)

Liam

[bhaagensen]

Hi,

Recent upgrades to Squeezecenter seems to be causing some problems for me. I get regular 'decoding error' messages in the terminal. I've had these messages occur for a while, but everything seemed to be working, so I did not care.

Recently the problems has become visible though. When playing a playlist and clicking e.g. next, sometimes this leads to skipping of several tracks before landing on one which will start playing. The pattern seems to be repeatable on the same playlist, but browser-refresh/reloading/stoping or whatever can change behavior so the tracks starts playing correctly again. Also clicking play on one of the skipped tracks usually does not work. After doing this for a while SC will end up playing some seemingly random tracknumber.

When loading one of the skipped tracks as a single-item playlist the track plays back fine.

Also this happens both on mp3 and flac files. Softsqueeze/SB3 works fine also.

I think these problems escalated after I installed the nightly latest as of January 10th. I'm not exactly sure which nightly I was running before that, but I only think it was at most a couple of days older.

Is this known? Fixes? Should I provide more info?

Thanks

Bjørn

Edit: This behavior happens on two computers, both with 0.7.3 and 0.7.4
Edit2: Changed the problem description as it seems to be a bit different than I first said.

Ubuntu 7.10
Squeezeslave-0.7.4

SqueezeCenter Version: 7.0 - 16145 - Debian - DA - utf8
Perl Version: 5.8.8 i486-linux-gnu-thread-multi
MySQL Version: 5.0.45-Debian_1ubuntu3.1
Platform Architecture: i686-linux

[Dominique]

Hi,
Recent upgrades to Squeezecenter seems to be causing some problems for me. [...]


Hi Bjørn,

I'm not running 7.0 yet, therefore I cannot offer much concrete help, so I will go fishing a bit:

. can you provide the complete command-line you use to start squeezeslave?
. are you in a position to compile a debug version and enable tracing in squeezeslave to see if you can isolate the problem?
. can you enable some tracing on the server side to see if any diagnostic would help narrowing down?
. do you confirm that you get decoder errors for flac? I'm also using flac here and, unless you have some fishy re-encoding going on on the server, the SC version should not even be able to cause decoding errors... Is there anyhing worth mentioning about your flac files (squeezeslave is staticly compiled with flac 1.2.0, in case it matters).

Hope I can help,

Dominique

[Emissary]

Hi, I'm getting the same problem. I've attached a short output of squeezeslave during a track change. If anything more is needed, I'm happy to help. The command line is "squeezeslave -d slimaudio -d slimproto 192.168.0.3".

[bhaagensen]

Thanks for your reply. I am really busy right now, but I'll try to provide more elaborate information when time allows. Emissary provided some information, and I'm keeping an eye on this thread so that I can help with info if necessary.

For what it's worth I'm getting now getting the 'flac decoding error 0' instead of 'decoding error'. This changed during one of the latest nightly upgrades. Also I'm starting with 'squeezeslave -v off -m xx:xx:xx:xx:xx:xx localhost', no transcoding, and the flac files are made using sound-juicer and EAC.

Bjørn

[ralphy]

I've finally managed to build a current version of squeezeslave for windows with all features except --retry. Initial testing is looking good. Not too sure if the --signal is actually working but the option is there. If all goes well, in the next day or two, I'll have Dominique put the new binary on sourceforge and add the few changes in svn that are required to build 0.7.4 successfully.

As part of the build I upgraded the FLAC libraries to 1.2.1 in the hopes that the decode error several people have been seeing lately with the latest SS 7.0 builds will be fixed by the updated version.

-Ralphy.

[bhaagensen]

As part of the build I upgraded the FLAC libraries to 1.2.1 in the hopes that the decode error several people have been seeing lately with the latest SS 7.0 builds will be fixed by the updated version.

-Ralphy.

That certainly is good news. I've been forced to use Softsqueeze for a while, and although it works, squeezeslave is a MUCH better solution for me.

Thanks,

Bjørn

[liam.whiteside]

Any particular reason for not implementing --retry? As a non C programmer I would have thought that compared with the audio and codec side of things, that would be fairly easy (but then I don't understand the code).

Currently having to restart SqueezeSlave when updating SC7 or restarting the server box is one of the annoyances I was hoping the new version of SqueezeSlave would be able to fix.

Liam

[oreillymj]

can someone tell me where the Windows binary is?

I was expecting to find it here

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494&release_id=532275

[ralphy]

Any particular reason for not implementing --retry? As a non C programmer I would have thought that compared with the audio and codec side of things, that would be fairly easy (but then I don't understand the code).Liam

It's a problem with the Windows mingw support libraries not supporting most of the unix signals, in the case of the retry option; SIGCHLD.

Currently having to restart SqueezeSlave when updating SC7 or restarting the server box is one of the annoyances I was hoping the new version of SqueezeSlave would be able to fix.Liam

I have the same problem using squeezeslave 0.7.4 on linux with the --retry option, I've never had the retry option successfully recover from an SC restart. Perhaps Dominque can shed some light on this.

[ralphy]

can someone tell me where the Windows binary is?

I was expecting to find it here

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494&release_id=532275

I'm still testing the new version. I've had three copies of the new 0.7.4 windows squeezeslave binary playing a mix of mp3, flac and wav files overnight and it hasn't missed a beat. While ogg is also supported, I don't have any ogg files in my music library.

As I don't have upload access to the sourceforge site, I have to get someone to upload the zip file for me; usually Dominique.

Eventually it will be available at that URL. I'll post to this thread, once it's there.

-ralphy

[oreillymj]

ok thanks.

[ralphy]

...I'll post to this thread, once it's there.

Squeezeslave 0.7.4 for win32 is now available for download at

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494

Dominique and I are currently investigating a way to implement the --retry option, which is not included in the 0.7.4 binary, using a platform neutral signal mechanism. Stay tuned for more info.

-ralphy

[ralphy]

Stay tuned for more info.

Squeezeslave 0.7.4.1 for win32 is now available for download from sourceforge.

http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494

Version 0.7.4.1 of squeezeslave includes the retry option. I've tested retry through numereous stops and starts of SlimServer 6.5.5 from the end of January and it recovered and reconnected every time.

Due to an editing problem on my part -r requires that you specify an interval in seconds and --retry does not work if you include an interval, but uses the default 3 seconds.

I've fixed this on my build system so the next release will function with the interval being optional for both forms of the command line option.

As there is a work around, I won't release another package at this time.

-ralphy

[Bradley]

I appreciate the efforts in this project, but I must report that both the 0.7.4 and 0.7.4.1 versions are using >95% CPU while not playing anything on my machine (running Windows XP SP2).

I've reverted back to the 0.7 version which behaves properly (never seeing > 3% CPU at any time).

*Bradley

[ralphy]

I appreciate the efforts in this project, but I must report that both the 0.7.4 and 0.7.4.1 versions are using >95% CPU while not playing anything on my machine (running Windows XP SP2).

I've reverted back to the 0.7 version which behaves properly (never seeing > 3% CPU at any time).

*Bradley

What version of SlimServer are you running? I've seen this if you're using the 6.5.x version and do not specify the -O or --oldplayer option.

-ralphy

[Philip Meyer]

>I appreciate the efforts in this project, but I must report that both
>the 0.7.4 and 0.7.4.1 versions are using >95% CPU while not playing
>anything on my machine (running Windows XP SP2).
>
I haven't noticed any problems with CPU load (AMD Athlon 64 X2 3800+, 2GB RAM).

However, I am finding that song transitions are not always smooth. Especially streaming LastFM radio stations - it never seems to play to the end of the stream (loses a few seconds).

Phil

[Bradley]

What version of SlimServer are you running? I've seen this if you're using the 6.5.x version and do not specify the -O or --oldplayer option.

-ralphy

Ralphy -- You da man! I am using Slimserver 6.5.4. Adding the -O option got the new squeezeslave working perfectly. Now I'm not seeing ANY measureable CPU strain on squeezeslave 0.7.4.1! Now I'll play a bunch of tracks and report any unusual observations.

Perhaps you guys should put a big note in the release notes about this issue and easy resolution?

Thanks so very much!

*Bradley

[ralphy]

Now I'll play a bunch of tracks and report any unusual observations.

Perhaps you guys should put a big note in the release notes about this issue and easy resolution?

*Bradley
Thanks to Bradley for pointing out the race condition when someone doesn't specify the --oldplayer option when running SqueezeCenter 6.5.x.

The -h option for squeezeslave, does a good job of explaining the current commandline options for a given version of squeezeslave.

Version 0.7.4.2 of squeezeslave for win32, which fixes this race condition, is available on sourceforge and the two previous releases of 0.7.4 have been removed. If you're currently running 0.7.4 or 0.7.4.1, please upgrade!

squeezeslave.exe -V

Displays which version of squeezeslave.exe you're using. Download the new version from http://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494.

Here's the commandline options I start squeezeslave with which has survived many stops and starts for SqueezeCenter 6.5.5 running on a separate linux machine.

"C:\Program Files\Squeezeslave\squeezeslave.exe" --oldplayer --signal --retry --mac "01:02:03:04:05" linuxhostname

Ralphy.

[ralphy]

>I am finding that song transitions are not always smooth. Especially streaming LastFM radio stations - it never seems to play to the end of the stream (loses a few seconds).
Phil
Phil,

Please upgrade to the newest version 0.7.4.2 and let me know if you're still experiencing this problem. This may have been related to the race condition that Bradley reported. If not, we'll look into it.

Are you streaming from your sound card via coax or a toslink cable? I've also experienced problems with track transitions using the coax link on my SB Live 5.1, which is in a Linux box however, not windows. Using the analog out provides much cleaner track changes.

Dominique has been working on a way to keep external DACs active during track changes and to get them active before the initial start of a playlist. No idea of a timeframe for this release though, as it's still a work in progress.

-Ralphy.

[Philip Meyer]

Hi ralphy,

>Please upgrade to the newest version 0.7.4.2 and let me know if you're
>still experiencing this problem. This may have been related to the
>race condition that Bradley reported. If not, we'll look into it.
>
Okay, I'll try that later.

However, I thought the race condition was only SS 6.5.4. I'm running SC7 on WinXP Pro SP2. I'm using a simple 2.1 speaker output from a Creative Audigy 2ZS.

Phil

[ralphy]

However, I thought the race condition was only SS 6.5.4. I'm running SC7 on WinXP Pro SP2. I'm using a simple 2.1 speaker output from a Creative Audigy 2ZS.

Phil

Actually, the race condition has always been there. It just so happened that Bradley found a reliable way to recreate it. The race condition is in the part of the code that reads data via a socket from slim server and is not really version specific.

-ralphy

[Philip Meyer]

I've just tried it again.

I've been launching SqueezeSlave from Moose - don't know if that makes a difference. I then use the default webUI skin to start LastFM "My Neighbours". This plays tracks, but is still cutting off the end of each track.

I also noticed this in the log:

[16:30:44.4518] Slim::Display::Display::string (802) Error: missing string WELCOME_TO_SQUEEZESLAVE
[16:30:44.4524] Slim::Display::Display::string (802) Backtrace:

frame 0: Slim::Utils::Log::logBacktrace (P:/Music/SlimServer/trunk/server/Slim/Display/Display.pm line 802)
frame 1: Slim::Display::Display::string (P:/Music/SlimServer/trunk/server/Slim/Player/Player.pm line 153)
frame 2: Slim::Player::Player::string (P:/Music/SlimServer/trunk/server/Slim/Player/Player.pm line 241)
frame 3: Slim::Player::Player::power (P:/Music/SlimServer/trunk/server/Slim/Player/Player.pm line 97)
frame 4: Slim::Player::Player::init (P:/Music/SlimServer/trunk/server/Slim/Player/Squeezebox.pm line 38)
frame 5: Slim::Player::Squeezebox::init (P:/Music/SlimServer/trunk/server/Slim/Player/SqueezeSlave.pm line 62)
frame 6: Slim::Player::SqueezeSlave::init (P:/Music/SlimServer/trunk/server/Slim/Networking/Slimproto.pm line 1011)
frame 7: Slim::Networking::Slimproto::_hello_handler (P:/Music/SlimServer/trunk/server/Slim/Networking/Slimproto.pm line 377)
frame 8: Slim::Networking::Slimproto::client_readable (P:/Music/SlimServer/trunk/server/Slim/Networking/Select.pm line 243)
frame 9: (eval) (P:/Music/SlimServer/trunk/server/Slim/Networking/Select.pm line 243)
frame 10: Slim::Networking::Select::select (P:\Music\SlimServer\trunk\server\slimserver.pl line 503)
frame 11: main::idle (P:\Music\SlimServer\trunk\server\slimserver.pl line 453)
frame 12: main::main (P:\Music\SlimServer\trunk\server\slimserver.pl line 1005)


Phil

[mherger]

> [16:30:44.4518] Slim::Display::Display::string (802) Error: missing string WELCOME_TO_SQUEEZESLAVE

http://bugs.slimdevices.com/show_bug.cgi?id=7203 - thanks!

--

Michael

[Dominique]

Hi all,

Sorry for my long absence, I was busy ripping and listening to music.
One thing that has started annoying me is that some part of my setup
wakes up too late when starting to play a song (could be the PC's
optical output or preamp's optical in). Some songs have audible
samples very early in the track and I just could not hear them.

So I added a pre-delay feature in squeezeslave 0.7.5.

From the squeezeslave doc (squeezeslave -h):

-p, --predelay <msec>:

Sets a delay before any playback is started. This is useful if the DAC used for
output is slow to wake-up/lock, causing the first few samples to be dropped.

-a, --predelay_amplitude <val>:

Sets the amplitude of a high-frequency tone produced during the predelay (see
--predelay). The frequency is set at the source's sampling rate/2 and the
amplitude is in absolute value. For 16-bit sources, the max is 32767, but values
below 10 are likely to work. The goal is to produce an inaudible signal that will
cause DACs to wake-up and lock before actual samples are played out. If the DAC
locks using only silence, do not use this option (it will default to 0).


The "-a" option may seem controversial, but it is the only way my preamp lets
me hear those early samples: it won't wake up with just silent pre-delay
samples. The signal being 22050Hz and as faint as possible, it is inaudible
in practice. An amplitude of 3 and a delay of 680ms works perfectly well for
me.

My squeezeslave startup is getting crowded so for the curious, here is the
command I use:

/usr/local/bin/squeezeslave --signal --retry --predelay 1000 --predelay_amplitude 3 --volume sw --oldplayer

The command sits in a file called ~/.config/autostart/Squeeze Slave.desktop.
Under xubuntu (with proper parameters in this file) this causes squeezeslave
to start with the session whenever I boot and log into the machine.

You'll find the linux, windows and solaris binaries on sourceforge, right here:

https://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494&release_id=532275

If you feel like contributing a binary for another platform, just post a message
to this thread and I'll pick it up.

Apart from this new feature, version 0.7.5 incorporates many fixes for infinite
loops, race conditions, --retry on windows and documentation touch ups.

Thanks to everybody who report their problems here and help
fixing/diagnosing them (ralphy, stand up!).

Enjoy

Dominique

[DanielTheGreat]

Because SoftSqueeze is such a dog (resource hog, and unreliable), I use Squeezeslave to play flac files from my server (in sync with one or two Squeezebox 3's). I've been running Squeezeslave 0.7 binary for Win32, but with frequent 'Flac decoder error' messages and other flaky behaviour, I went looking for a later version and downloaded 0.7.5 from SourceForge. But as soon as I run it it gives me this message (after the usual sign-on stuff):

Error in recv 1: No error

and remains silent. Is this a known problem? Is anyone working on it? In the meantime I'm back with V0.7.

Another request: would the person(s) updating Squeezeslave please display the version number in the sign-on messages, so I can see what version I'm running at any time.

Many thanks,
Daniel

[ralphy]

But as soon as I run it it gives me this message (after the usual sign-on stuff):

Error in recv 1: No error

and remains silent. Is this a known problem? Is anyone working on it? In the meantime I'm back with V0.7.

Another request: would the person(s) updating Squeezeslave please display the version number in the sign-on messages, so I can see what version I'm running at any time.

Many thanks,
Daniel

Are you running version 6.5.x of slimserver? If so, you need to add --oldplayer to the command line.

squeezeslave.exe -V

Gives you the version of squeezeslave, -h displays all the options.

Also, squeezeslave 0.7.5 uses a newer threads and flac dll than 0.7.0, so make sure you're using the matching dlls for the version you're running.

ralphy.

[Bradley]

I've been testing SC7 and SqueezeSlave 0.7.5 with all sorts of SC7 features. Everything is working great except, strangely, Live365, where everything sounds like Chipmunks. I'm also noticing it on another Internet Radio URL I use, but not on RadioIO, Shoutcase, Sirius or Alien BBC.

I'm not particularly a fan of Live365, but I'd think everyone should be experiencing the same thing on their end.

Please let me know what you find.

*Bradley

[DanielTheGreat]

Ralphy, thanks for the tips. I was running 6.5.4 of SlimServer (and I had the correct dll's for the new Squeezeslave). But I've since upgraded to SqueezeCenter 7, and re-tried Squeezeslave 0.7.5 - it seems to work fine now.
Whether it's more stable than 0.7 remains to be seen - I won't know till I've done my 'full weekend' test, when SC7 runs for 2 days solid with 2 SB3's plus Squeezeslave all synced together.
Daniel

[bernt]

Hi!

What are the commandline options for Squeezeslave?

My goal is to run it headless\background on Windows.

Is that possible?

Kind Regards
/Bernt

[KeyzerSuze]

Hi

a big thanks to Dominique for all the work. I am new to squeeze. I bought a squeezebox and I used to use softsqueeze (in headless mode), I had made the assumption that squeezeslave (sl) was an early version of ss.

My aim is to run headless and in audio shared mode, it would be nice to get the alsa capable stuff in place.

I also noticed that there aren't any amd64 builds in the download section. Which is not really a problem, the ia32 works for me, except when I try and run it with aoss :(

I will see if I can get a amd64 build out of the svn tree, have to find out all the dev libraries i need.

just to add to the wishlist

* alsa compatible sound
* a deb for squeezeslave

edit:
I have attached a patch for compiling under amd64, just a FLAAC callback datatype change

I have run the amd64 compiled version, with aoss (64bit) and all seems to be working fine. any one else want this compiled version ?

In regards to the native access to alsa and the planned move to SDL libraries, is the a time line for this. The reason I am asking is I was thinking of looking at the PA libraries and moving up to the version that defaults to alsa instead of oss, as a stop gap, eliminating the need for aoss

[ralphy]

any one else want this compiled version ?


If you can provide me with a URL for the binary, I'll get it uploaded to the squeezeslave downloads on sourceforge. Would it be possible to link it against the static versions of libmad, libFLAC, libvorbisfile, libvorbis and libogg, if it is not already? That would reduce the number of issues people will have with running different versions of these support libraries.


In regards to the native access to alsa and the planned move to SDL libraries, is the a time line for this. The reason I am asking is I was thinking of looking at the PA libraries and moving up to the version that defaults to alsa instead of oss, as a stop gap, eliminating the need for aoss

There has currently no plans to move to SDL. It was suggested a while back, when it looked like squeezeslave was going to be used with the Jive controller. But it sounds like SD is going to use the code from the SB instead, so there really is no need anymore.

-Ralphy

[rtitmuss]

There has currently no plans to move to SDL. It was suggested a while back, when it looked like squeezeslave was going to be used with the Jive controller. But it sounds like SD is going to use the code from the SB instead, so there really is no need anymore.

I have recently started developing the audio playback for SqueezePlay (the new name for the Jive application). This uses portaudio v19, and supports native alsa playback. It turns out the SDL audio did not support all the features needed. The code is at a very early stage of development, but hopefully I'll have an alpha release in a few weeks time.

Richard

[ralphy]

I have recently started developing the audio playback for SqueezePlay (the new name for the Jive application). This uses portaudio v19, and supports native alsa playback. It turns out the SDL audio did not support all the features needed. The code is at a very early stage of development, but hopefully I'll have an alpha release in a few weeks time.

Richard

Thanks for the update.

[KeyzerSuze]

If you can provide me with a URL for the binary, I'll get it uploaded to the squeezeslave downloads on sourceforge. Would it be possible to link it against the static versions of libmad, libFLAC, libvorbisfile, libvorbis and libogg, if it is not already? That would reduce the number of issues people will have with running different versions of these support libraries.

http://www.samad.com.au/~alex/squeezeslave

ldd squeezeslave
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b2c5f4bb000)
libm.so.6 => /lib/libm.so.6 (0x00002b2c5f6d6000)
libc.so.6 => /lib/libc.so.6 (0x00002b2c5f957000)
/lib64/ld-linux-x86-64.so.2 (0x00002b2c5f29d000)



There has currently no plans to move to SDL. It was suggested a while back, when it looked like squeezeslave was going to be used with the Jive controller. But it sounds like SD is going to use the code from the SB instead, so there really is no need anymore.

-Ralphy
Hi

So what i can gather from this is Softsqueeze and squeezeslave are set to die, because they will be replaced by jive (now called Squeeze Os & Squeeze Play). Will they be as small and simple as squeezeslave - I love it because, I set it to run on machine startup (linux) and when not in use I can still use the sound card with other programs (with the use of aoss).

Has anyone looked at the difficulty in going to portaudio v19 for squeezeslave ?

Alex

[rtitmuss]

So what i can gather from this is Softsqueeze and squeezeslave are set to die, because they will be replaced by jive (now called Squeeze Os & Squeeze Play).

Softsqueeze and squeezeslave are community projects, I started both before working for Slim Devices/Logitech and neither are offically supported. They will only die once the community is no longer interested in supporting them.

Will they be as small and simple as squeezeslave - I love it because, I set it to run on machine startup (linux) and when not in use I can still use the sound card with other programs (with the use of aoss).

SqueezePlay is designed to run on embedded ARM devices, if it's not small and simple we'll have problems. I am planning on supporting headless playback with SqueezePlay, but not in the first alpha releases. The intention is also to make SqueezePlay feature complete compared to Squeezebox (e.g. replay gain, crossfade, etc), the only exceptions maybe some music services were we are restricted by licensing.

Has anyone looked at the difficulty in going to portaudio v19 for squeezeslave ?

I really don't think the effort is worthwhile, hopefully SqueezePlay will become the preferred desktop application for playback soon.

Richard

[DanielTheGreat]

Hi all,

Sorry for my long absence, I was busy ripping and listening to music.
One thing that has started annoying me is that some part of my setup
wakes up too late when starting to play a song (could be the PC's
optical output or preamp's optical in). Some songs have audible
samples very early in the track and I just could not hear them.

So I added a pre-delay feature in squeezeslave 0.7.5.

From the squeezeslave doc (squeezeslave -h):

-p, --predelay <msec>:

Sets a delay before any playback is started. This is useful if the DAC used for
output is slow to wake-up/lock, causing the first few samples to be dropped.

-a, --predelay_amplitude <val>:

Sets the amplitude of a high-frequency tone produced during the predelay (see
--predelay). The frequency is set at the source's sampling rate/2 and the
amplitude is in absolute value. For 16-bit sources, the max is 32767, but values
below 10 are likely to work. The goal is to produce an inaudible signal that will
cause DACs to wake-up and lock before actual samples are played out. If the DAC
locks using only silence, do not use this option (it will default to 0).

---------- snip ----------

Dominique

I've learned a lot from reading this thread :-)

My system too suffered from missing early samples, so I thought I'd try the -p <msec> -a <val> feature, setting the delay time initially to 700.

I'm not missing any early samples now, BUT the Squeezeslave runs 700ms behind the SB3 player it's synced with, which is very annoying when I'm in the part of the house where I can hear both sets of speakers.

I guess SqueezeCenter doesn't know about Squeezeslave's -p parameter?

Daniel

[awy]

I guess SqueezeCenter doesn't know about Squeezeslave's -p parameter?

Daniel

No, but you can adjust for it by going to Settings / Players / <player> / Audio / Player Audio Delay, assuming SC 7.0.

[DanielTheGreat]

No, but you can adjust for it by going to Settings / Players / <player> / Audio / Player Audio Delay, assuming SC 7.0.

Ah, yes, thanks Awy. I'm still finding my way around SC7 :-)
Daniel

[bobkoure]

I've just tried SqueezeSlave and it does some ... odd things.
When I play an album, say, it jumps immediately to the third song in the album. If I then click the first song in the album (using the SqueezeCenter web interface) I get a snippet of sound (which might be from the first song and might be from somewhere else) - and then it jumps right back to that third song.
It seems to play OK, goes from one tune to the next OK, but If I click on another album (again, in the SC web interface) it just stops.

Probably unrelated: I'd used the SC "settings" page to "name" squeezeslave on the PC it was running on it. When I tried running it on a different PC, it came up with that same name (so not differentiated by MAC).

I'm running Squeezeslave as a simple dosbox exe (not a service) on a WinXP SP2 machine, I'm running SqueezeCenter 7.0 on a machine running Win2K Server.

Anyone got suggestions?
Thanks!
Bob

[sandos]

Unfortunately I do not, I have the exact same issues though. Squeezeslave is pretty much unusable with SC 7.0, and now it started stopping playing songs half-way through, too!

[bradsjm]

Unfortunately I do not, I have the exact same issues though. Squeezeslave is pretty much unusable with SC 7.0, and now it started stopping playing songs half-way through, too!
I solved the stopping songs half way through issue with SC 7 by using the -O squeezeslave flag to tell it to identify itself as an older player (6.5.x I guess compatible). No idea why, but this fixed it! It fixed the behaviour that it would get part way through a song from Slacker or Pandora and just start the next song.

Still can't get it to sync with a regular Squeezebox though, neither devices plays anything if I try that.

Otherwise, it is working great :)

Btw, Squeezeslave defaults to identifying itself as MAC 01:01:01:01:01:01 unless you change that on the command line so it will show up with the same name no matter what box you run it on.

[awy]

Still can't get it to sync with a regular Squeezebox though, neither devices plays anything if I try that.


Hmm, I wonder what you folk have for a problem. It works fine for me. What platform are you having problems with? You could try turning on debug for player.sync info for player.source and see if you get any insights.

[JJZolx]

I've just tried SqueezeSlave and it does some ... odd things.
When I play an album, say, it jumps immediately to the third song in the album. If I then click the first song in the album (using the SqueezeCenter web interface) I get a snippet of sound (which might be from the first song and might be from somewhere else) - and then it jumps right back to that third song.
It seems to play OK, goes from one tune to the next OK, but If I click on another album (again, in the SC web interface) it just stops.

I'm seeing this same behavior with SC7 when connecting from a remote network. Also, the 'now playing' in the status area does not update. I get this behavior with both the new Default skin and any other skin. But... I see it with both Squeezeslave and Softsqueeze.

[awy]

I take back my previous posting. Something horrible is happening.

[awy]

I did a bit of quick digging around.

A generic linux_i386 build did not work properly on my FC8 linux_x86_64 system. Lots of stupid stuff happened, like skipping songs, only play half a second or so, etc. - as reported earlier in this thread. I have not bothered to investigate why except to note that silly things are happening at the SlimProto level.

A native build on linux_x86_64 worked fine - unsynced.

Then I played around some more. Clearly some timing-related things going on. I think the attached patch would help. There are still some problems in the server with regard to use of reportsTrackStart() and assumptions around it.

Synced - this depended upon the soundcard. I have two cards on my system: (a) HDA-Intel - HDA ATI SB Realtek ALC883, (b) Audigy SE [SB0570] CA106. With (a) it is hopeless, with (b) it works just fine.

This seems to be down to the accuracy of reports from the portaudio v18 Pa_StreamTime() function. This is clearly different for different card and driver stacks. A google search turns up plenty of discussion about the problems with it: for example, http://www.techweb.rfa.org/pipermail/portaudio/2002-February/000479.html

[ralphy]

I think the attached patch would help.


I've built a new release of squeezeslave which includes Alan's slimaudio_decoder.c.patch and I also included the flaac.patch from Alex to fix 64 bit builds, which is more for completeness than anything else as it doesn't affect the win32 version.

https://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494&release_id=532275

Ralphy.

[awy]

I did not check my patch into subversion because I'm not sure that it is sufficient or complete. Although I am pretty sure that it is better than before.

Also I checked in a change to SC7 trunk (will come in 7.0.1 release or current nightlies) which should make squeezeslave work better, especially with the other patch above.

I'm afraid that I do not have time at the moment to look at this in any more detail.

Alan.

[chrisla]

I did not check my patch into subversion because I'm not sure that it is sufficient or complete. Although I am pretty sure that it is better than before.

Also I checked in a change to SC7 trunk (will come in 7.0.1 release or current nightlies) which should make squeezeslave work better, especially with the other patch above.

I'm afraid that I do not have time at the moment to look at this in any more detail.

Alan.

Thanks Alan!

That fixed skipping back and forth in the web interface / half played songs for me. If the server side patches fix the the now playing info, I'll be golden.

It's great to finally have a fully functional squeezeslave, great tool to breath new life into old laptops/machines.

-Chris

[awy]

Yes, Now Playing is the most visible thing that the server patch should fix.

If others are happy with the squeezeslave patch then I'll check it in.

[seroper]

Hi,

I'm just about to order a Duet, but am also interested in squeezeslave for playback on a windows PC. I've read lots about squeezeslave now and I'm keen to get involved. Can anyone please help me get started with the following questions?

1) Can squeezeslave be controlled by the new squeeze controller?
2) Does anyone have a VC++ 2008 express edition project setup for squeezeslave - I'd like to try building and enhancing the program but don't know how to start (I'm an embedded programmer, not windows normally)
3) I don't think squeezeslave currently supports ASIO output. I'd really like to get a bit perfect player. Portaudio includes ASIO, so can squeezeslave be rebuild with a windows ASIO libuary included?

Many thanks,

Simon.

[KeyzerSuze]

I did a bit of quick digging around.

A generic linux_i386 build did not work properly on my FC8 linux_x86_64 system. Lots of stupid stuff happened, like skipping songs, only play half a second or so, etc. - as reported earlier in this thread. I have not bothered to investigate why except to note that silly things are happening at the SlimProto level.

A native build on linux_x86_64 worked fine - unsynced.

Then I played around some more. Clearly some timing-related things going on. I think the attached patch would help. There are still some problems in the server with regard to use of reportsTrackStart() and assumptions around it.

Synced - this depended upon the soundcard. I have two cards on my system: (a) HDA-Intel - HDA ATI SB Realtek ALC883, (b) Audigy SE [SB0570] CA106. With (a) it is hopeless, with (b) it works just fine.

This seems to be down to the accuracy of reports from the portaudio v18 Pa_StreamTime() function. This is clearly different for different card and driver stacks. A google search turns up plenty of discussion about the problems with it: for example, http://www.techweb.rfa.org/pipermail/portaudio/2002-February/000479.html


I was having the same problem, then realised i was still running slimserver, i have upgraded to squeeze center - nice. I have applied the above patch and recompile for amd64


ldd squeezeslave
libpthread.so.0 => /lib/libpthread.so.0 (0x00002b65b3406000)
libm.so.6 => /lib/libm.so.6 (0x00002b65b3621000)
libc.so.6 => /lib/libc.so.6 (0x00002b65b38a2000)
/lib64/ld-linux-x86-64.so.2 (0x00002b65b31e8000)


its at http://www.samad.com.au/~alex/squeezeslave, if somebody can grab it and put it back up on sorceforge.

Time I think to look at jive

[JJZolx]

I'm seeing this same behavior with SC7 when connecting from a remote network. Also, the 'now playing' in the status area does not update. I get this behavior with both the new Default skin and any other skin. But... I see it with both Squeezeslave and Softsqueeze.

I just downloaded and installed 0.7.5.1 (running on Windows, connecting to SC 7.0.1 from a remote network) and it seems to have sorted out the playlist and Now Playing confusion.

One thing still happening - and this has been off and on with SoftSqueeze as well since I first started using it a couple years ago: When I manually skip or change tracks there's always a short, 1/10th to 1/2 second burst of sound just before the start of the new track playing. Normal track transitions are fine. Listening to a number of these sound bursts, I'm pretty certain that I can recognize that they're from the song that was interrupted. Anyone else hearing the same thing, and is there a workaround for the problem?

[JJZolx]

I just downloaded and installed 0.7.5.1

Also doesn't seem to want to stay connected to the server and disappears from the web interface of SC7. The keepalive ability doesn't appear to be working.

[sierramike]

Hi Folks,

I've read some messages of this thread, very interresting ... And I've got a problem !

In fact I've just built a Linux Box using an old P3 1GHz, put Debian Etch on it, SSH, Samba, SqueezeCenter 7, and all is working now perfectly. SoftSqueeze beeing ran on my laptop under Vista connects good to the server and throws music ...

But I would like a good player headless on the Linux Box, which contains a soundcard, without the annoying delay of mpg123 ... I discovered SqueezeSlave which is really promising, but it doesn't run !

I downloaded the Win32 version for a test from my laptop, it works, but when I start playing a new playlist it jumps to the last song (my test playlists are 2 or 3 songs long ...) rather than starting from the begining. I have to restart the same playlist to have it start correctly.

Also, I see lots of decoding errors in the console window where I started SqueezeSlave ...

I'd love to try the linux version but it complains about missing GLIBC_2.4 ... which I found wasn't ported on the Debian distrib as it was an experimental version only ... Would it be any chance you could compile it using another version of GLIBC ?

I wanted to try to compile it myself but for a linux newbie that's not so evident ... (I'm a programmer for my job, but using C#.NET, some years ago I used VC++6 for PocketPC programming, and learned a little bit C/C++ programming at university on Unix/Linux PC's).

But when I do :
svn co http://svn.slimdevices.com/repos/slim/trunk/softsqueeze
It complains that this URL doesn't exists ... So I did :
svn co http://svn.slimdevices.com/repos/slim
And it downloaded hundreds of megabytes data ...
I found in ~/slim/7.0/trunk/softsqueeze/SlimProtoLib/src/ a directory called squeezeslave with a unique squeezeslave.c file but how do I compile that ?

Any help / tutorial that could help me would be appreciated ! I would be pleased to then learn building a deb package and propose SqueezeSlave as a deb package for Debian users !

Please help me ! Thanks a lot !

[Dominique]

Hi sierramike,

Welcome to this thread; I started it a while ago (I'm a bit behind right now) and it is somewhat becoming the squeezeslave portal.

To compile squeezeslave on linux, go in the SlimProtoLib directory, and issue "make -f makefile.linux". The reason you don't see a makefile with squeezeslave.c is that the files in the other directories (slimproto, slimaudio) need to be compiled as well. The makefile.linux file takes care of compiling those.

You may need to install other packages in order for the compile to work: libmad0-dev, libflac-dev, libvorbis-dev, etc. I don't remember all of them by heart, but if the compile/link fails, just Google-up the missing library and you should be able to figure out what you need to install to keep going.

Hope this helps, tell us what you find. If you have time/knowledge to make a debian package, this would be really nice.

Dominique

[Dominique]

Hi

a big thanks to Dominique for all the work.


You're welcome. Note there are other contributers that participate to this thread.


I am new to squeeze. I bought a squeezebox and I used to use softsqueeze (in headless mode), I had made the assumption that squeezeslave (sl) was an early version of ss.


I was also surprised at how little "advertised" squeezelave was when I picked it up (I understood after, when I saw the problems it had ;)


My aim is to run headless and in audio shared mode, it would be nice to get the alsa capable stuff in place.


This would require moving up to Portaudio V19 (we're at 18 now). It's also one of my itches that squeezeslave hogs the audio output. I'll add this to my todo!


I also noticed that there aren't any amd64 builds in the download section. Which is not really a problem, the ia32 works for me, except when I try and run it with aoss :(

I will see if I can get a amd64 build out of the svn tree, have to find out all the dev libraries i need.


I have received the build by e-mail, I will upload it today.


just to add to the wishlist

* alsa compatible sound
* a deb for squeezeslave


A deb package is really asked often. If you can offer a link to a quick primer of how to do this, I may take a look or maybe you can look into it if you have time. Whoever attempts this, please coordinate with others on this thread to avoid duplicating efforts.


edit:
I have attached a patch for compiling under amd64, just a FLAAC callback datatype change


I have integrated your patch to a batch of changes I will submit shortly. Thanks a lot!

I have run the amd64 compiled version, with aoss (64bit) and all seems to be working fine. any one else want this compiled version ?


In regards to the native access to alsa and the planned move to SDL libraries, is the a time line for this. The reason I am asking is I was thinking of looking at the PA libraries and moving up to the version that defaults to alsa instead of oss, as a stop gap, eliminating the need for aoss

Any help appreciated. I don't have privileges to grant access rights to the repository, however. Richard Titmuss is the coordinator, if I am right.

Sorry if some of my answers are off beat: I'm a bit behind (had a rush at work...).

Thanks for your comments/help,

Dominique

[Dominique]

Yes, Now Playing is the most visible thing that the server patch should fix.

If others are happy with the squeezeslave patch then I'll check it in.

Hi Alan,

I have just upgraded to SqueezeCenter 7.0, and immediately got the skipped songs problem that others are describing. I'm getting these problems without attempting any sync playback.

As already reported, using --oldplayer fixes this because as you know, this option causes squeezeslave to be considered as a softsqueeze instead of a close relative of squeezebox (v1). I'm in no way an expert in perl and squeezecenter, but if you could provide just a few pointers for what to look for, I'll try to debug this.

Not sure I understood your last mail: did you commit a fix for this in the development version ? (it seemed to be for some other problem).

Thanks,

Dominique

[JJZolx]

I have just upgraded to SqueezeCenter 7.0, and immediately got the skipped songs problem that others are describing. I'm getting these problems without attempting any sync playback.

As already reported, using --oldplayer fixes this because as you know, this option causes squeezeslave to be considered as a softsqueeze instead of a close relative of squeezebox (v1). I'm in no way an expert in perl and squeezecenter, but if you could provide just a few pointers for what to look for, I'll try to debug this.

Hmmmm. As I mentioned in a earlier post, I just installed Squeezeslave 0.7.5.1 with SqueezeCenter 7.0 (on Windows) and that alone solved problems I was seeing with skipped songs. Without the --oldplayer switch.

[Dominique]

Hmmmm. As I mentioned in a earlier post, I just installed Squeezeslave 0.7.5.1 with SqueezeCenter 7.0 (on Windows) and that alone solved problems I was seeing with skipped songs. Without the --oldplayer switch.

OK, let's compare setups then, if you have a few minutes.

My command line to start squeezeslave is:


/home/dom/slim/slave/src/SlimProtoLib/bin/squeezeslave --volume sw --predelay 680 --predelay_amplitude 3 --signal --retry --oldplayer


From the status page on the web interface:


SqueezeCenter Information

SqueezeCenter Version: 7.0 - 17793 - Debian - EN - iso-8859-1
Server IP address: 192.168.1.2
Perl Version: 5.8.8 i486-linux-gnu-thread-multi
MySQL Version: 5.0.45-Debian_1ubuntu3.3


What you call 0.7.5.1 is 0.7.5 with Alan's patch for slimaudio_decoder.c, right?

Thanks for your help,

Dominique

[JJZolx]

OK, let's compare setups then, if you have a few minutes.

My command line to start squeezeslave is:


/home/dom/slim/slave/src/SlimProtoLib/bin/squeezeslave --volume sw --predelay 680 --predelay_amplitude 3 --signal --retry --oldplayer


-s -k 8 -r 2 -m 01:01:01:01:01:0F 192.168.9.3 0

From the status page on the web interface:


SqueezeCenter Information

SqueezeCenter Version: 7.0 - 17793 - Debian - EN - iso-8859-1
Server IP address: 192.168.1.2
Perl Version: 5.8.8 i486-linux-gnu-thread-multi
MySQL Version: 5.0.45-Debian_1ubuntu3.3


SqueezeCenter Version: 7.0.1 - TRUNK - Windows XP - EN - cp1252
Server IP address: 192.168.9.3
Perl Version: 5.8.7 MSWin32-x86-multi-thread
MySQL Version: 5.0.54-enterprise-gpl-nt-log

Platform Architecture: 586

What you call 0.7.5.1 is 0.7.5 with Alan's patch for slimaudio_decoder.c, right?

Yes, from http://64.72.236.146/downloads/squeezeslave-0.7.5.1-win32.zip

[Dominique]

SqueezeCenter Version: 7.0.1 - TRUNK - Windows XP - EN - cp1252
Server IP address: 192.168.9.3
Perl Version: 5.8.7 MSWin32-x86-multi-thread
MySQL Version: 5.0.54-enterprise-gpl-nt-log

Platform Architecture: 586

Aha! You're using 7.0.1 and I'm using 7.0. I'll try upgrading and report back here later this week.

Thanks for helping out,

Dominique

[awy]

Hi Alan,

I have just upgraded to SqueezeCenter 7.0, and immediately got the skipped songs problem that others are describing. I'm getting these problems without attempting any sync playback.

As already reported, using --oldplayer fixes this because as you know, this option causes squeezeslave to be considered as a softsqueeze instead of a close relative of squeezebox (v1). I'm in no way an expert in perl and squeezecenter, but if you could provide just a few pointers for what to look for, I'll try to debug this.

Not sure I understood your last mail: did you commit a fix for this in the development version ? (it seemed to be for some other problem).



I committed the SC patch as it was a general problem that needed fixing. It makes the now-playing information correct. It is in the SC 7.0.1 nightly.

I did not commit the squeezeslave patch as I did not have time to decide if it was really correct. It is probably correct but not necessarily sufficient under all circumstances. It stops the skipping. The issue is that the precise circumstances under which the different types of underrun message (STMd, SMTu, STMo) should be sent are critical to proper operation. Feel free to apply (checkin) my patch if all seems to work properly for you.

Alan

[KeyzerSuze]

You're welcome. Note there are other contributers that participate to this thread.



Thanks to the other people :), reads like you gave some life to the project agin.


I was also surprised at how little "advertised" squeezelave was when I picked it up (I understood after, when I saw the problems it had ;)



This would require moving up to Portaudio V19 (we're at 18 now). It's also one of my itches that squeezeslave hogs the audio output. I'll add this to my todo!


The impression I got from reading some other replies to this request that jive was going to be the way to go for headless playback.

I am wondering weather it is worth looking at the move to V19 ? seeing as jive seems (by reading the web site) ready, I have yet to try it though.



I have received the build by e-mail, I will upload it today.



A deb package is really asked often. If you can offer a link to a quick primer of how to do this, I may take a look or maybe you can look into it if you have time. Whoever attempts this, please coordinate with others on this thread to avoid duplicating efforts.

Should be simple, I could lend a hand if somebody would like to take the lead




I have integrated your patch to a batch of changes I will submit shortly. Thanks a lot!

I have run the amd64 compiled version, with aoss (64bit) and all seems to be working fine. any one else want this compiled version ?



Any help appreciated. I don't have privileges to grant access rights to the repository, however. Richard Titmuss is the coordinator, if I am right.

That would imply some responsibility - have my hands full with a 7 month old right now



Sorry if some of my answers are off beat: I'm a bit behind (had a rush at work...).

Thanks for your comments/help,

Dominique

[wmertens]

Just thought I'd drop a quick message: I compiled the svn version (gotten from http://svn.slimdevices.com/repos/slim/7.0/trunk/softsqueeze ) on OS X, both on Intel and PowerPC and both seem to work just fine with minimal CPU.

Thanks to everyone for making it work! Especially for PowerPC, because I think there might be an endianness issue with SoftSqueeze: x86 server, PPC player => garbled audio.

I did notice some weirdness with it playing other things than the iPeng skin was showing but once I tried to investigate using the default skin it just worked in both skins. Ah well.

Wout.

[pippin]

I did notice some weirdness with it playing other things than the iPeng skin was showing but once I tried to investigate using the default skin it just worked in both skins. Ah well.


Do you have more than one player connected?

Now: When's somebody compiling this for iPhone ;-)?

[hellesangel]

Hi,

I'm also getting the same error as above: lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by /usr/local/slimserver/squeezeslave/squeezeslave)" and then discovered I can't find the Squeezeslave sources to try to recompile them.

Anyone know where they are?

[ralphy]

Anyone know where they are?

svn co http://svn.slimdevices.com/repos/slim/trunk/softsqueeze

[hellesangel]

Thanks, but that gives me:

> svn co http://svn.slimdevices.com/repos/slim/trunk/softsqueeze
svn: URL 'http://svn.slimdevices.com/repos/slim/trunk/softsqueeze' doesn't exist

Are the Squeezeslave sources in the same place?

Edit: The link should be http://svn.slimdevices.com/repos/slim/7.0/trunk/softsqueeze/ and I don't see the Squeezeslave sources there.

[wmertens]

Do you have more than one player connected?

Now: When's somebody compiling this for iPhone ;-)?

No, I don't. Actually I think it might be that bug with song skipping people are talking about here, so I should upgrade my SC. I'll try it later today.

As for the iPhone, it shouldn't be too hard to port most of it. The hard part would be portaudio, and handling all the network transitions the iPhone does. If I sleep my mac, squeezeslave doesn't recover after waking up, I need to restart it...

[wmertens]

The link should be http://svn.slimdevices.com/repos/slim/7.0/trunk/softsqueeze/ and I don't see the Squeezeslave sources there.

Go into SlimProtoLib and run "make -f makefile.YOUROSHERE". Make sure you have all the dependencies installed.

[hellesangel]

Thanks for the tip, it appears I don't have all dependencies - is there a thread somewhere that describes how to get this set up? I assume there is but I haven't found it yet.

The pertinent errors seem to be:
src/slimaudio/slimaudio.h:31:17: error: mad.h: No such file or directory
src/slimaudio/slimaudio.h:32:33: error: FLAC/stream_decoder.h: No such file or directory
src/slimaudio/slimaudio.h:33:31: error: vorbis/vorbisfile.h: No such file or directory

They hint at the missing parts but leave some work to be done. Any help much appreciated.

[bhaagensen]

Thanks for the tip, it appears I don't have
all dependencies - is there a thread somewhere that describes how to
get this set up? I assume there is but I haven't found it yet.

The pertinent errors seem to be: src/slimaudio/slimaudio.h:31:17:
error: mad.h: No such file or directory
src/slimaudio/slimaudio.h:32:33: error: FLAC/stream_decoder.h: No such
file or directory src/slimaudio/slimaudio.h:33:31: error:
vorbis/vorbisfile.h: No such file or directory

They hint at the missing parts but leave some work to be done. Any help much appreciated.

Which OS? If on Linux you need the header files for mad, flac, and
vorbis. Some are included I think, but I don't know which build's using them. Not Linux I belive. Meny distros ship development-packages with the .h files separately. Just install them. That's all I can say not knowing more about your system
etc. Also have a look in the makefiles to see where header files are
being included from.

[hellesangel]

Many thanks for your help. I'm using SuSE Linux 10.0 and yesterday night managed to find the FLAC sources here: http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=12677 and OGG/Vorbis here: http://www.xiph.org/svn/ and MAD here: ftp://ftp.mars.org/pub/mpeg/.

Unfortunately I got stuck again trying to persuade the OGG/Vorbis configure script to run as it needs autoconf and other tools I didn't have available, but by fiddling with the makefile to add include paths FLAC and MAD seem OK.

Somehow I feel there must be an easier way than manually downloading, installing and configuring each package independently and then manually figuring the makefile but then perhaps not...

[bhaagensen]

Many thanks for your help. I'm using SuSE Linux 10.0 and yesterday night managed to find the FLAC sources here: http://sourceforge.net/project/showfiles.php?group_id=13478&package_id=12677 and OGG/Vorbis here: http://www.xiph.org/svn/ and MAD here: ftp://ftp.mars.org/pub/mpeg/.



Don't do that. Unless you really know what you are doing you could end up with a messed up system with non-working flac and worse. As i said, most dist ship dev packages separately. Go with those. I'm sure they are avalable in yum, or whatever the package manager is called in suse.

[alexho]

Running Server 7.0, same firewall zone, 1GBit Ethernet
Other devices are running smooth, however

squeezeslave 0.7.5-17618 (on XP SP2 32bit) suffers this serious problem:

Skipping a song (all MP3s 320k VBR) always causes:
http_recv: error reading from socket
decoding error
decoding error

Skipping to a previous song is not possible, squeezeslave picks a different song than the one I clicked on, also the same errors are logged. Sometimes playback just stutters and halts.

I would also like to add that I think it is a very good idea to fix squeezeslave, because it seems like the most portable and lightweight client code.

[KeyzerSuze]

svn co http://svn.slimdevices.com/repos/slim/trunk/softsqueeze

I just tried an update against this
http://svn.slimdevices.com/repos/slim/trunk/softsqueeze, but it failed

I have also co out

http://svn.slimdevices.com/repos/slim/7.0/trunk, which has softsqueeze in there.

Question is should I be checking out 7.0 (stable) or 7.1 (unstable) ?

alex

[ralphy]

Running Server 7.0, same firewall zone, 1GBit Ethernet
Other devices are running smooth, however

squeezeslave 0.7.5-17618 (on XP SP2 32bit) suffers this serious problem:

Try using the 0.7.5.1 win32 squeezeslave client. Link available a few pages back in this thread.

Also, upgrade to a 7.01 nightly build. The fix required changes to both squeezecenter and squeezeslave.

Ralphy

[alexho]

The "special" 7.5.1 build located at http://64.72.236.146/downloads/squeezeslave-0.7.5.1-win32.zip did the trick for me - even when running the 7.0 Server (SqueezeCenter Version: 7.0 - 17793 - Windows Server 2003). But of course I'll upgrade the server to 7.01

Is this a fork or are the changes checked in?
Curios: What/where was the server fixed?

Was it an implementation problem, or is the SlimProtoTCPProtocol itself the problem? (looking at the quite elegant design of the server and SqueezePlay/Jive, the protocol suite seems quite a bit odd to me... :))

Again, thank you so much!!!

[KeyzerSuze]

I have got a patch to work with portaudio_v19.

it compiles, it runs, but the sounds is way too low (I have to turn to full to get a little sounds out of the speakers). so it is not really working but its a start. I have left in (commented) all the lines changes. the code could be beautified, but I thought i would send this out anyway

its against svn 18483

patch is attached

you will need
http://www.portaudio.com/archives/pa_stable_v19_20071207.tar.gz just untar it in
SlimProtoLib/lib. then apply the patch from softsqueeze directory.

note I am not a portaudio (nor squeezeslave) programmer so take it as it is.

hopefully this is a good start to portaudio v19

edit: i will try and fix the sounds volume issue then all should be okay. I have also added the patch as an attachment to this post

edit2: fixed the volume added new attachment (I have removed it from my web site, seeing as you can get it from here.

edit3: fixed the patch again, had to set the outbound sample rate to 44100, not to what the sound card is capable off! (working patch is v3)

[ralphy]

The "special" 7.5.1 build
Is this a fork or are the changes checked in?
Curios: What/where was the server fixed?


This version includes a 1-line patch from Alan that, as far as I know, has not been checked in to tree. You'll find the patch earlier in this thread.

Ralpy

[KeyzerSuze]

If somebody else could test a compiled squeezeslave with portaudio_v19, I am seeing some strange things, but I am also tracking 7.1 trunk so I am not sure which is causing my problems (some times songs are being skipped in playlists). I have also had to make some changes to the way the client starts and stop stream (ie don't close an already closed stream)

http://www.samad.com.au/~alex/squeezeslave (its for amd64)

[ralphy]

If somebody else could test a compiled squeezeslave with portaudio_v19, I am seeing some strange things, but I am also tracking 7.1 trunk so I am not sure which is causing my problems (some times songs are being skipped in playlists). I have also had to make some changes to the way the client starts and stop stream (ie don't close an already closed stream)

I built a 32bit linux version on the weekend. I didn't see any of the problems you describe. However, I'm still using SS 6.5.5. I also have included Alan's and your patch in my source tree, but neither have any effect in my environment. Did you have Alan's patch applied?

I did notice that the sound was constantly breaking up, not enough to be called a drop out, but enough for it to be annoying to listen to, going back to portaudio v18 and reloading the aoss driver, the audio was solid again.

Ralphy

[KeyzerSuze]

I built a 32bit linux version on the weekend. I didn't see any of the problems you describe. However, I'm still using SS 6.5.5. I also have included Alan's and your patch in my source tree, but neither have any effect in my environment. Did you have Alan's patch applied?

I did notice that the sound was constantly breaking up, not enough to be called a drop out, but enough for it to be annoying to listen to, going back to portaudio v18 and reloading the aoss driver, the audio was solid again.

Ralphy

Great (somebody has tried it), no I did not have Alan's patch. It seems like there was some changes to the openstream and associated call back functions.
Mine seems to be a bit more stable now I downgraded to an earlier version.

I will have a look at it. This was justa first going over it to see if I could get it to compile and hopefully work. This time I will have a bit more of a look through the doc and see what I can do.

Thanks

[alexho]

It essential for those of us running 7.x Servers - so please check in the "magic line". Thanks!

[KeyzerSuze]

It essential for those of us running 7.x Servers - so please check in the "magic line". Thanks!

I can't seem to find the actual patch (I can find a few references for it), can somebody supply a link

[ralphy]

I can't seem to find the actual patch (I can find a few references for it), can somebody supply a link

SlimProtoLib/src/slimaudio/slimaudio_decoder.c 2008-04-12 08:44:44.000000000 -0400
SlimProtoLib/src/slimaudio/slimaudio_decoder.c 2008-03-19 07:39:58.000000000 -0400
@@ -150,7 +150,7 @@
}

DEBUGF("decoder_thread stopped\n");
- slimaudio_stat(audio, "STMd");
+ if (audio->decoder_state == STREAM_PLAYING) slimaudio_stat(audio, "STMd");

case STREAM_STOP:
pthread_mutex_lock(&audio->decoder_mutex);

[KeyzerSuze]

I have worked another patch to V19, it seems to be working with 19009 (there seem to be some bugs with ogg comment handling, which cause some problem with decoding ogg files some times.... if you wait squeezecenter & squeezeslave catch up with each other.

I have compiled it and tried it for a day or 2.

I have tidied up the patch a bit, I have changed from fix frame size (passing to portaudio) and I also pre load the PA Stream.

it seems like some of the problem before where with multiple releases of mutex's for the same reason.

I have attached the patch, note it is set to build a DEBUG version

Alex

EDIT: I might have spoken to soon - still skipping on another one of my machines! (this might had to to with the fact I was outputting direct to spdif, when I went back to analogue its all okay, something else to look into)
EDIT2: follow up on my spdif problem, I have updated my /etc/asound.conf to add buffering to my spdif channel and it has resolved my jumping problem when playing from squeezeslave. If any one is interested in the setup I can post. basically squeezeslave outputs via spdif and all other sound apps play via the normal analogue route (mplayer/xine/etc)

[ralphy]

I have worked another patch to V19, it seems to be working with 19009


That's great Alex!

I'll give it a try, but I probably won't get a chance until the weekend. If the audio is more consistant than before on my 32bit linux machine, I'll try building a win32 version as well and post it for others to try.

Ralphy.

[KeyzerSuze]

That's great Alex!

I'll give it a try, but I probably won't get a chance until the weekend. If the audio is more consistant than before on my 32bit linux machine, I'll try building a win32 version as well and post it for others to try.

Ralphy.

Been doing some of my own testing, I used to be able to sync 2 squeezeslaves and a SB3 together, now the SB3 is out by a fair bit (I am guessing because of the preloading I am doing with portaudio 19)

[oreillymj]

Perhaps this has already been asked, but I'd like to run Sqeezeslave as a service with no DOS window open.

Is there an option to not print anything to the console, which should avoid opening a DOS box.

Redirecting >NULL causes the app to not start correctly.

[Gplouffe]

Compiling packages for linux is like running with scissors for me. I have tried and get errors about .h stuff that should be there and is not, and so far as I can see, it is. Anyone tell me what I am doing wrong?

squeeze:/mnt/ftp/squeezeslave# make -f makefile.linux
gcc -Wall -Werror -O3 -c -Ilib/portaudio_v18/pa_common -Ilib/portaudio_v18/pablio -Ilib/portmixer/px_common -Isrc src/squeezeslave/squeezeslave.c -o src/squeezeslave/squeezeslave.o
In file included from src/squeezeslave/squeezeslave.c:29:
src/slimaudio/slimaudio.h:28:23: error: portaudio.h: No such file or directory
src/slimaudio/slimaudio.h:29:23: error: portmixer.h: No such file or directory
src/slimaudio/slimaudio.h:31:17: error: mad.h: No such file or directory
src/slimaudio/slimaudio.h:32:33: error: FLAC/stream_decoder.h: No such file or directory
src/slimaudio/slimaudio.h:33:31: error: vorbis/vorbisfile.h: No such file or directory
In file included from src/squeezeslave/squeezeslave.c:29:
src/slimaudio/slimaudio.h:85: error: expected specifier-qualifier-list before ‘PortAudioStream’
cc1: warnings being treated as errors
src/squeezeslave/squeezeslave.c: In function ‘main’:
src/squeezeslave/squeezeslave.c:270: warning: implicit declaration of function ‘Pa_Sleep’
make: *** [src/squeezeslave/squeezeslave.o] Error 1
squeeze:/mnt/ftp/squeezeslave#

Thanks!

Guy

[KeyzerSuze]

Compiling packages for linux is like running with scissors for me. I have tried and get errors about .h stuff that should be there and is not, and so far as I can see
Guy

Won't try and debug you errors, but will tell you how mine is setup

I have checked out
http://svn.slimdevices.com/repos/slim/7.1/trunk/softsqueeze/SlimProtoLib

when I am in SlimProtolib and do a svn info i get


Repository Root: http://svn.slimdevices.com/repos/slim
Repository UUID: 60ad55ce-86ed-0310-8cf8-f9d879be5ea1
Revision: 19185
Node Kind: directory
Schedule: normal
Last Changed Author: dominique
Last Changed Rev: 17602
Last Changed Date: 2008-02-18 12:02:30 +1100 (Mon, 18 Feb 2008)


from here I can run make -f makefile.linux

I am running on unstable amd64 debian, I had to install some -dev packages, from memory I think

libmad0-dev
libvorbis-dev
libflac-dev


This should produce something in bin for you

[KeyzerSuze]

That's great Alex!

I'll give it a try, but I probably won't get a chance until the weekend. If the audio is more consistant than before on my 32bit linux machine, I'll try building a win32 version as well and post it for others to try.

Ralphy.

Seems like I am having some break up again on a machine that i wasn't having problems with before !

Can you tell me (if you are having the problem) if you are using software volume controll

[ralphy]

Seems like I am having some break up again on a machine that i wasn't having problems with before !

Can you tell me (if you are having the problem) if you are using software volume controll

I always turn it off with --volume off and am still experiencing break up with the new patch. I was playing around with it yesterday and was able to reproduce the break up consistantly by doing any CPU intensive activity. Compiling was exceptionally bad.

My test machine is running a linux 2.4.34.5 kernel on a 2.4GHz Pentium 4 which has never had the drop outs using the older portaudio v18.1 library. I also run that same older version on a pentium MMX 133MHz laptop running linux with an 802.11b wireless connection, streaming Wave, FLAC and MP3 files and never misses a beat.

Perhaps the buffer is not large enough to handle the peaks in CPU utilization?

Ralphy.

[KeyzerSuze]

I always turn it off with --volume off and am still experiencing break up with the new patch. I was playing around with it yesterday and was able to reproduce the break up consistantly by doing any CPU intensive activity. Compiling was exceptionally bad.

My test machine is running a linux 2.4.34.5 kernel on a 2.4GHz Pentium 4 which has never had the drop outs using the older portaudio v18.1 library. I also run that same older version on a pentium MMX 133MHz laptop running linux with an 802.11b wireless connection, streaming Wave, FLAC and MP3 files and never misses a beat.

Perhaps the buffer is not large enough to handle the peaks in CPU utilization?

Ralphy.

This has been my reasoning as well, I have been adding debuging information through squeezeslave to watch the buffers and they seem okay the http-> decoder-> output. I have tried increasing them to no avail.

The place it blocks is writing to the decoder buffer (just read off http and trying to write to decoders buffer.

I have let portaudio ask for the number of frames to transfer on its call back and it seems to default to 1024 (it was hard coded as 256 before), I have tried placing this back again to no avail, there is more buffer interaction, but the waits are still in the same place.

I am running on a 64 X2 Dual Core Processor 4400+ so I should not be getting this problem. One other thing I have noticed is file with higher bitrate seem to suffer more from this as well.

The main differences is v18 -> v19 and going from the /dsp to pcm via alsa. I notice more problems when I output straight to the spdif, right now I have it outputting via dmixer.

I will have more of a play with it, might also talk to the portaudio people (maybe get a new version of v19)

[KeyzerSuze]

I always turn it off with --volume off and am still experiencing break up with the new patch. I was playing around with it yesterday and was able to reproduce the break up consistantly by doing any CPU intensive activity. Compiling was exceptionally bad.

My test machine is running a linux 2.4.34.5 kernel on a 2.4GHz Pentium 4 which has never had the drop outs using the older portaudio v18.1 library. I also run that same older version on a pentium MMX 133MHz laptop running linux with an 802.11b wireless connection, streaming Wave, FLAC and MP3 files and never misses a beat.

Perhaps the buffer is not large enough to handle the peaks in CPU utilization?

Ralphy.


I have compiled against svn tag 1381 of portaudio and it seems to be better, I have seen some differences in my debug output.

New issue, it renumbers the alsa devices so check the list !

if you can check it out

EDIT:
I tested by playing a track through sc (sc and squeezeslave on the same box) and played another music track with mplayer. Did not seem to have any sound problems! Not an exhaustive test but

[ralphy]

if you can check it out



I tried it today with a portaudio snapshot from May 2nd. Unfortunately, there's no difference. Still experiencing drop outs when the CPU utilization spikes. It's not a big deal for me as the laptop I use squeezeslave on only has oss drivers installed and I have an SB3 in my office next to the alsa linux machine.

I'll be happy to test any updates.

Ralphy

[KeyzerSuze]

I tried it today with a portaudio snapshot from May 2nd. Unfortunately, there's no difference. Still experiencing drop outs when the CPU utilization spikes. It's not a big deal for me as the laptop I use squeezeslave on only has oss drivers installed and I have an SB3 in my office next to the alsa linux machine.

I'll be happy to test any updates.

Ralphy


Thanks, can you tell me what sort of compression ie mp3,ogg,flac ? I created a test flac file, encoded at quality 9, played that via squeezeslave and then at the same time played another ogg files (with mplayer) and sent the cpu it a busy loop with a small shell script.

I would like to be able to reproduce this at will so I can test.

I have tried to stay away from looking at the portaudio code, but my gut is telling me v19 isn't as ready as v18 :(

EDIT:
Is any one interested in V19, my initial interest was based around the want to use alsa not oss, which can be solved with aoss.

My Question for the thread is: Is it worth trying to track down the problem with V19

[st2000]

I have a user that is having problems. His album collection is over
1400 labels. I don't have nearly that many. Is there an easy way to
simulate a large collection?

....thanks

[st2000]

stuart wrote:
> I have a user that is having problems. His album collection is over
> 1400 labels. I don't have nearly that many. Is there an easy way to
> simulate a large collection?
>
> ...thanks

I've had a look through my code and can't imagine "int"'s not being
large enough to hold the values for a 1000+ album collection. Although
I wonder about the value of album_id returned from squeezecenter (aka
slimserver).

How is the album_id generated?

How large of a number should I expect?

....thanks

[bhaagensen]

I've had a look through my code and can't imagine "int"'s not being
large enough to hold the values for a 1000+ album collection. Although
I wonder about the value of album_id returned from squeezecenter (aka
slimserver).


Many people are running libraries with >10000 albums. May I ask what the exact problem is that you are having?

Regards Bjørn

[gharris999]

I have a user that is having problems. His album collection is over
1400 labels. I don't have nearly that many. Is there an easy way to
simulate a large collection?

....thanks

http://forums.slimdevices.com/showpost.php?p=296496&postcount=21

[st2000]

bhaagensen wrote:
> st2000;298956 Wrote:
>>
>> I've had a look through my code and can't imagine "int"'s not being
>> large enough to hold the values for a 1000+ album collection. Although
>>
>> I wonder about the value of album_id returned from squeezecenter (aka
>> slimserver).
>>
>
> Many people are running libraries with >10000 albums. May I ask what
> the exact problem is that you are having?
>
> Regards Bjørn

Sorry if I didn't make my self clear. My SqueezeCenter client is
crashing. It is written in C and runs on a powerpc platform.

I am thinking values associated with a large collection may be the
problem. However, after a quick look through my code I couldn't see any
obvious errors.

Regardless, it would be good to at least represent a large number of
albums to test the client's code.

[ralphy]

Thanks, can you tell me what sort of compression ie mp3,ogg,flac ?

I tried mp3, flac and wav files. My mp3 files are created with lame 3.97 --preset extreme and flac v1.2.1 with -8.

My Question for the thread is: Is it worth trying to track down the problem with V19

Perhaps a poll is in order?

[st2000]

gharris999 wrote:
> st2000;298928 Wrote:
>> I have a user that is having problems. His album collection is over
>> 1400 labels. I don't have nearly that many. Is there an easy way to
>> simulate a large collection?
>>
>> ....thanks
>
> http://forums.slimdevices.com/showpost.php?p=296496&postcount=21
>

Apologies in advance for being a complete newbie w.r.t. the mysql aspect
of SqueezeBox, but...

The instructions in the above link assume I have, what, SqueezeBox 7.0
installed? I haven't warmed up to that new Logitec "I agree to" legal
gibberish in order to download 7.0 so I am still running 6.5.4.

So does that mean I can't use this data base?

If I can, I still have other issues I need to understand. The
instructions are to untar the different files and the resulting
directory structure can just be "swapped in". Humm, well I'll assume I
don't want to put files into /var/lib/squeezecenter/cache/MySQL but
rather into /usr/local/slimserver/Cache/MySQL, right?

Also, I'll assume I need to change ownership to slimserver and not
squeezecenter.

Now comes the basic mySql question: These files, they are not directly
used by squeezecenter (aka slimserver) are they? The are used by mysql
on behalf of squeezecenter, right?

....thanks for you help

[andyg]

On May 7, 2008, at 10:04 AM, stuart wrote:

>
>
> gharris999 wrote:
>> st2000;298928 Wrote:
>>> I have a user that is having problems. His album collection is over
>>> 1400 labels. I don't have nearly that many. Is there an easy way
>>> to
>>> simulate a large collection?
>>>
>>> ....thanks
>>
>> http://forums.slimdevices.com/showpost.php?p=296496&postcount=21
>>
>
> Apologies in advance for being a complete newbie w.r.t. the mysql
> aspect
> of SqueezeBox, but...
>
> The instructions in the above link assume I have, what, SqueezeBox 7.0
> installed? I haven't warmed up to that new Logitec "I agree to" legal
> gibberish in order to download 7.0 so I am still running 6.5.4.

No need to do that, just go to http://www.slimdevices.com/downloads/nightly/latest/trunk/
to get the latest 7.0.1 build.

[tcutting]

I've been testing SC7 and SqueezeSlave 0.7.5 with all sorts of SC7 features. Everything is working great except, strangely, Live365, where everything sounds like Chipmunks. I'm also noticing it on another Internet Radio URL I use, but not on RadioIO, Shoutcase, Sirius or Alien BBC.

I'm not particularly a fan of Live365, but I'd think everyone should be experiencing the same thing on their end.

Please let me know what you find.

*Bradley

I am still having the same issues described here. I am running the 0.7.5.1 version of SqueezeSlave on Windows XP, against latest nightly SC (May 8th). Has anyone determined cause/fix for this? I've found squeezeslave to be now more robust than softsqueeze as a simple player, but am trying to get reliable connections to some local internet radio stations.
Other than that, however, squeeseslave seems to be a great utility - after reading through this thread, I really appreciate the hard work that's gone into making this a usefull too.

[st2000]

Is this the accepted way of pulling album covers:

"http://localhost:9000/music/99/cover"

I ask because if I do this:

"http://localhost:9000/music/99/cover.jpg"

....then the squeezecenter server assumes any files it finds is a JPG.
You literally have to dissect the file with an open mind it could be
anything at the client to find out otherwise.

---

Also, could someone w/no album art running 6.5.4 or older (i.e.
slimserver) test if "http://localhost:9000/music/99/cover" works with a
browser? You should get the default slimserver PNG image of 2 eighth notes.


....thanks

[andyg]

On May 9, 2008, at 2:36 PM, stuart wrote:

>
> Is this the accepted way of pulling album covers:
>
> "http://localhost:9000/music/99/cover"

This will return the best available image, basically that means JPEG
for square source images and transparent PNG for non-square images.
The content-type will tell you what kind of file you have. This is
our preferred method now, because before we were always using huge PNG
files for everything, but for most cases a square JPEG is better and a
lot smaller.

> I ask because if I do this:
>
> "http://localhost:9000/music/99/cover.jpg"
>
> ...then the squeezecenter server assumes any files it finds is a JPG.
> You literally have to dissect the file with an open mind it could be
> anything at the client to find out otherwise.

cover.jpg will always give you a JPEG, likewise cover.png will always
give you a PNG. If you see otherwise, please file a bug. Please
include a log with the 'artwork' debug setting enabled.

[awy]

I am still having the same issues described here. I am running the 0.7.5.1 version of SqueezeSlave on Windows XP, against latest nightly SC (May 8th).

Do you know what sample-rate/channels/sample-size is used by live356? SqueezeSlave is hard-wired to 44100/2/16. If you play it on a normal player then you can see from the track info (go RIGHT in Now Playing).

[awy]

Do you know what sample-rate/channels/sample-size is used by live356? SqueezeSlave is hard-wired to 44100/2/16. If you play it on a normal player then you can see from the track info (go RIGHT in Now Playing).

A colleague looked at one just now. It was 22000 frames/s. So no chance with SqueezeSlave.

[st2000]

stuart wrote:
> Is this the accepted way of pulling album covers:
>
> "http://localhost:9000/music/99/cover"

Specifically, does this work in slimserver 6.5.4? I can't test this as
I've already upgraded to squeezecenter 7.0.1.

....thanks everyone for your help.

[rtitmuss]

Please see http://forums.slimdevices.com/showpost.php?p=303480&postcount=1 for details for SqueezePlay with audio playback.

Richard

[ggalt]

I have tried to stay away from looking at the portaudio code, but my gut is telling me v19 isn't as ready as v18 :(

EDIT:
Is any one interested in V19, my initial interest was based around the want to use alsa not oss, which can be solved with aoss.

My Question for the thread is: Is it worth trying to track down the problem with V19

I'm interested in v19 as the continued support for v18 by the portaudio team seems to be questionable.

I'm just coming back to squeezeslave from some time off, so I'm not sure which of the various patches to apply and to which versions of squeezeslave. I assume I should be patching against 7.1 trunk, or should I move to 7.2?

George

[KeyzerSuze]

I'm interested in v19 as the continued support for v18 by the portaudio team seems to be questionable.

I'm just coming back to squeezeslave from some time off, so I'm not sure which of the various patches to apply and to which versions of squeezeslave. I assume I should be patching against 7.1 trunk, or should I move to 7.2?

George

I did a bit of survey, not much enthusiasm for v19. Plus I was pointed back to squeezeplay (jive), I am going to have a look at that.

That patches were against 7.1, I am still using my compiled client - occasionally I get a hiccup not enough to be a pain, say once a week that I notice.

[erlis]

I'm having problem compiling under mac os x 10.5.1.

The line 55 in lib/portaudio_v18/pa_common/pa_host.h needs to be commented out sometimes and there sometimes.

I've however managed to compile squeezeslave 0.7.5 for os x.

First run:
tekpc4846:SlimProtoLib fer$ make -f makefile.osx all
gcc -DSLIMPROTO_DEBUG -c -Ilib/portaudio_v18/pa_common -Ilib/portaudio_v18/pablio -Ilib/portmixer/px_common -Isrc lib/portmixer/px_mac_core/px_mac_core.c -o lib/portmixer/px_mac_core/px_mac_core.o
In file included from lib/portmixer/px_mac_core/px_mac_core.c:47:
lib/portaudio_v18/pa_common/pa_host.h:55: error: conflicting types for ‘uint32’
/System/Library/Frameworks/Security.framework/Headers/cssmconfig.h:64: error: previous declaration of ‘uint32’ was here
make: *** [lib/portmixer/px_mac_core/px_mac_core.o] Error 1

commented out line 55 in pa_host.h

2:nd run:
--snip--
gcc -DSLIMPROTO_DEBUG -c -Ilib/portaudio_v18/pa_common -Ilib/portaudio_v18/pablio -Ilib/portmixer/px_common -Isrc lib/portaudio_v18/pa_common/pa_lib.c -o lib/portaudio_v18/pa_common/pa_lib.o
In file included from lib/portaudio_v18/pa_common/pa_lib.c:54:
lib/portaudio_v18/pa_common/pa_host.h:78: error: syntax error before ‘uint32’

enabled line 55 in pa_host.h

3:rd run:
gcc -DSLIMPROTO_DEBUG -c -Ilib/portaudio_v18/pa_common -Ilib/portaudio_v18/pablio -Ilib/portmixer/px_common -Isrc lib/portaudio_v18/pa_common/pa_lib.c -o lib/portaudio_v18/pa_common/pa_lib.o
gcc -DSLIMPROTO_DEBUG -c -Ilib/portaudio_v18/pa_common -Ilib/portaudio_v18/pablio -Ilib/portmixer/px_common -Isrc lib/portaudio_v18/pa_common/pa_convert.c -o lib/portaudio_v18/pa_common/pa_convert.o
gcc -DSLIMPROTO_DEBUG -c -Ilib/portaudio_v18/pa_common -Ilib/portaudio_v18/pablio -Ilib/portmixer/px_common -Isrc lib/portaudio_v18/pablio/ringbuffer.c -o lib/portaudio_v18/pablio/ringbuffer.o
ar cru lib/libportaudio.a lib/portaudio_v18/pa_mac_core/pa_mac_core.o lib/portaudio_v18/pa_common/pa_lib.o lib/portaudio_v18/pa_common/pa_convert.o lib/portaudio_v18/pablio/ringbuffer.o
ranlib lib/libportaudio.a
gcc -o bin/squeezeslave src/squeezeslave/squeezeslave.o lib/portmixer/px_mac_core/px_mac_core.o lib/libslimproto.a lib/libportaudio.a -L/opt/local/lib -L/usr/local/lib -lmad -lFLAC -lvorbisfile -lvorbis -logg /System/Library/Frameworks/CoreAudio.framework/CoreAudio /System/Library/Frameworks/AudioToolbox.framework/AudioToolbox -lpthread

tekpc4846:SlimProtoLib fer$ bin/squeezeslave -V
squeezeslave 0.7.5


Note: I've removed -Wall as a CFLAG to make the output readable..

[ggalt]

I did a bit of survey, not much enthusiasm for v19. Plus I was pointed back to squeezeplay (jive), I am going to have a look at that.

That patches were against 7.1, I am still using my compiled client - occasionally I get a hiccup not enough to be a pain, say once a week that I notice.

My concern with working with squeezeplay/jive is the Logitech "open" license that comes with it. Softsqueeze and squeezeslave are GPL'd, but the Logitech license says that I can't do anything with the code other than use it myself. Since I've used squeezeslave code as the basis for 2 other projects (a softsqueeze clone written in C++ and Qt, and a plugin for MythTV), I'm not able to move to squeezeplay, at least for the second project above -- the first one I pretty much use only for myself and my family.

I don't know if there has been any push to get Slimdevices/Logitech to reconsider the license under which they are releasing squeezeplay, but the Logitech license significantly reduces my interest in that project.

George

[KeyzerSuze]

My concern with working with squeezeplay/jive is the Logitech "open" license that comes with it. Softsqueeze and squeezeslave are GPL'd, but the Logitech license says that I can't do anything with the code other than use it myself. Since I've used squeezeslave code as the basis for 2 other projects (a softsqueeze clone written in C++ and Qt, and a plugin for MythTV), I'm not able to move to squeezeplay, at least for the second project above -- the first one I pretty much use only for myself and my family.

I don't know if there has been any push to get Slimdevices/Logitech to reconsider the license under which they are releasing squeezeplay, but the Logitech license significantly reduces my interest in that project.

George

Interesting, I haven't actually looked at the licensing (naive), but this is just for home use and any one else that can benefit.


I am out travelling right now, but I was going to spend a bit of time looking at the sp code supposidly they are using v19, see what they have done. Then maybe fix up the squeezeslave stuff.

[ralphy]

Interesting, I haven't actually looked at the licensing (naive), but this is just for home use and any one else that can benefit.


I am out travelling right now, but I was going to spend a bit of time looking at the sp code supposidly they are using v19, see what they have done. Then maybe fix up the squeezeslave stuff.

I tried squeezeplay earlier this week and Richard is using PA v19. It's very cool! However, squeezeplay's memory footprint is huge compared to squeezeslave, not to mention CPU utilization, I'll never get it to run on my old laptop, like squeezeslave, especially since I don't have X installed on it. I think the fact that Squeezeplay currently needs the jive desktop and GUI to run makes it a different animal from squeezeslave. I for one would be interested in figuring out what's up with the portaudio v19 problem and maybe seeing what's involved in removing the 44.1 only stream playback limitation.

Perhaps the licensing is part of why Logitech seems to be trying to get everyone to move away from squeezeslave.

Long live squeezeslave, runs in under 8MB of memory and 2% CPU on my linux system.

Ralphy

[rtitmuss]

I tried squeezeplay earlier this week and Richard is using PA v19. It's very cool! However, squeezeplay's memory footprint is huge compared to squeezeslave, not to mention CPU utilization, I'll never get it to run on my old laptop, like squeezeslave, especially since I don't have X installed on it. I think the fact that Squeezeplay currently needs the jive desktop and GUI to run makes it a different animal from squeezeslave.

It should be possible to make SqueezePlay run headless. I think most of the memory and cpu used by SqueezePlay is for the UI, not the audio playback. Also remember at the moment SqueezePlay has not been optimized at all, at the moment the effort is directed at completing the functionality. I will be looking at optimization later in the project.

Perhaps the licensing is part of why Logitech seems to be trying to get everyone to move away from squeezeslave.

Not at all, it just makes sense not to duplicate the effort. SqueezePlay is going to be the official desktop player, and also used on the Controller. This is mostly a direct port from the Squeezebox firmware, and will be a fully featured player. I'd like your help to improve SqueezePlay.

The license has been discussed before, see http://forums.slimdevices.com/showthread.php?t=41672. Some features of SqueezePlay will also be closed and only available in our official binary releases, for example wma and rhapsody support. These features use code licensed from third parties, so clearly we have to be careful how SqueezePlay is licensed.

Richard

[pippin]

I think most of the memory and cpu used by SqueezePlay is for the UI, not the audio playback.

So can it be run without? Or does it have to be a resource hog like SoftSqueeze?

[dean]

On May 21, 2008, at 9:10 AM, ggalt wrote:
> My concern with working with squeezeplay/jive is the Logitech "open"
> license that comes with it. Softsqueeze and squeezeslave are GPL'd,
> but the Logitech license says that I can't do anything with the code
> other than use it myself. Since I've used squeezeslave code as the
> basis for 2 other projects (a softsqueeze clone written in C++ and Qt,
> and a plugin for MythTV), I'm not able to move to squeezeplay, at
> least
> for the second project above -- the first one I pretty much use only
> for
> myself and my family.
>
> I don't know if there has been any push to get Slimdevices/Logitech to
> reconsider the license under which they are releasing squeezeplay, but
> the Logitech license significantly reduces my interest in that
> project.

The future of that license is definitely under discussion. With the
first version, we were pretty conservative in order to make sure that
we weren't opening up the code to copycat manufacturers to clone the
Squeezebox controller.

We would love to open things up in order to protect our hardware
business while supporting our open source developer community to do
great things.

-dean

[dean]

On May 22, 2008, at 6:13 AM, pippin wrote:

>
> rtitmuss;304198 Wrote:
>>
>> I think most of the memory and cpu used by SqueezePlay is for the UI,
>> not the audio playback.
>
> So can it be run without?
Not yet. Richard looking at how to run it without any GUI at all.
Anybody who wants to help, please speak up!


> Or does it have to be a resource hog like
> SoftSqueeze?
It doesn't have to be. For one thing, it isn't implemented in java. :)

It _is_ likely to have a larger footprint than SqueezeSlave. It will
do a lot more and be a lot more flexible, in part due to the Lua
runtime, but also it will support more codecs and have features like
crossfade, replay-gain, and all the other stuff that's in Squeezebox
(and more).

Remember, though, that SqueezePlay runs on a 200MHz ARM9 with 64M of
total RAM. It might be hard to get it to run on a laptop with specs
much below this.

SqueezePlay _is_ going to be where our team here is going to put the
most effort in the future, in both the Squeezebox Controller and the
desktop versions, but also for some future hardware products.

[pippin]

On May 22, 2008, at 6:13 AM, pippin wrote:

> Or does it have to be a resource hog like
> SoftSqueeze?
It doesn't have to be. For one thing, it isn't implemented in java. :)

as long as it isn't perl... :)

Remember, though, that SqueezePlay runs on a 200MHz ARM9 with 64M of
total RAM. It might be hard to get it to run on a laptop with specs
much below this.


The ONLY platform I REALLY need a player on is my iPod, and that one does already have a nice GUI, so no need for that ;-)

[ralphy]

It should be possible to make SqueezePlay run headless. I think most of the memory and cpu used by SqueezePlay is for the UI, not the audio playback. Also remember at the moment SqueezePlay has not been optimized at all, at the moment the effort is directed at completing the functionality. I will be looking at optimization later in the project.


That great!

I have, on occasion, wished that squeezeslave (SS) did have all the functionality of my SB3s. But 99% of the time it does what I need for streaming at work and on the deck. Two places were it's not ideal to have an SB.

I think perhaps squeezeplay (SP) is too early in the development stage to tell people to start using it over SS. But since most of the current versions on sourceforge don't work with Squeezecenter (SC) v7.0.1, they don't have much choice.


I'd like your help to improve SqueezePlay.


I'm happy to help test SP. I was there back in Jan '06 to help you with code portability on linux, syncing with the SB3 and the testing of SS v0.1+ and will do what I can to help out with SP. I love the whole slimdevices music streaming system and can't wait for someone to ask "How are you playing that music?" when they're at my place.

<RANT>
That being said, I've asked several times for file management access to the SS download site on sourceforge, without receiving any response from you, one way or the other. I know you're busy, but you seem to have time to reply to posts on the forum. ;-)

I've been locally hosting the latest Windows version of SS v0.7.5.1 that works with the current SC. Dominique is busy with a new baby and hasn't been frequenting the forums lately, so I can't even ask him to place the files on sourceforge. I also have working Solaris SPARC, Solaris Intel and 32bit linux binaries, but only for my use at the moment.

Someone was recently trying to compile SS for OSX, a binary which has been lacking for a long time and it would be great to be able to get working binaries, for as many platforms as possible of SS on the download site as most of what's on SF now are all the older versions that don't work with the latest SC, which actually has a SS player type (8).
</RANT>

Lets not abandon SS until SP is up to the task.

Duane (AKA Ralphy)

[pippin]

Thanks, Ralphy!

BTW, yes, Wout compiled SS for OSX but it's not too stable and some things don't work correctly (e.g. skipping).

[tcutting]

Richard, et. al.-
I appreciate the work that went into SqueezeSlave (and SoftSqueeze) - and I agree that for many applications it's the best (current) application for local playback (small, low resource utilization, simple, decent compatibility w/ squeezecenter). I am looking forward to SqueezePlay as the probable replacement, but as I don't really have programming background, nor the tools to help with even compiling recent versions, there's not a lot I can contribute. From previous postings, someone suggested the I create the appropriate wiki page for SqueezeSlave, but as is noted in the previous post, the sourceforge repository isn't really up to date. That said, if someone else can be given access to update with the current version, I'd be willing to take a crack at the wiki to explain SqueezeSlave and point to the sourceforge downloads.
Again, we all appreciate the work and dedication it took to make this such a useful utility (kudos to Dominique as well!!!), and look forward to SqueezePlay, but think that for the near future SoftSqueeze is still a valuable tool which should continue to be supported.

Thanks!

Tom

[dean]

On May 24, 2008, at 11:42 AM, tcutting wrote:
> I am looking forward
> to SqueezePlay as the probable replacement, but as I don't really have
> programming background, nor the tools to help with even compiling
> recent versions, there's not a lot I can contribute.
There will be nightly builds of SqueezePlay available soon.


> From previous
> postings, someone suggested the I create the appropriate wiki page for
> SqueezeSlave, but as is noted in the previous post, the sourceforge
> repository isn't really up to date. That said, if someone else can be
> given access to update with the current version, I'd be willing to
> take
> a crack at the wiki to explain SqueezeSlave and point to the
> sourceforge
> downloads.
That would be great. Richard: I wonder if we should move SqueezeSlave
into the slimdevices svn repository...

> Again, we all appreciate the work and dedication it took to make this
> such a useful utility (kudos to Dominique as well!!!), and look
> forward
> to SqueezePlay, but think that for the near future SoftSqueeze is
> still
> a valuable tool which should continue to be supported.
Understood. Our goal is not to kill SqueezeSlave, but rather, make
SqueezePlay so much better that nobody would want anything else.

-dean

[rtitmuss]

I'm happy to help test SP. I was there back in Jan '06 to help you with code portability on linux, syncing with the SB3 and the testing of SS v0.1+ and will do what I can to help out with SP. I love the whole slimdevices music streaming system and can't wait for someone to ask "How are you playing that music?" when they're at my place.

Excellent, thanks.

<RANT>
That being said, I've asked several times for file management access to the SS download site on sourceforge, without receiving any response from you, one way or the other. I know you're busy, but you seem to have time to reply to posts on the forum. ;-)

I'm not sure how you've been trying to contact me, but I've never received any requests from you for Sourceforge access. I would be more than happy to arrange that, please email me at richard dot titmuss at logiech dot com and I will give you the necessary permissions.

Richard

[rtitmuss]

That would be great. Richard: I wonder if we should move SqueezeSlave
into the slimdevices svn repository...


It is, in a sub-directory under SoftSqueeze. I think the problem is the binaries available on sourceforge need updating.

Richard

[ralphy]

I would be more than happy to arrange that, please email me at richard dot titmuss at logiech dot com and I will give you the necessary permissions.

Richard

Thanks Richard!

Contacting you off thread.

Duane.

[ralphy]

Thanks, Ralphy!

BTW, yes, Wout compiled SS for OSX but it's not too stable and some things don't work correctly (e.g. skipping).

The skipping is due to a patch required for SC7.0.1. Actually there are a couple of patches provided by several people reading this thread that need to be applied to the squeezeslave source in svn. I've attached all 4 from my local source tree, which I've been using with SC7.0.1 for some time now. Would someone please apply these to the svn version?

flacc.patch <- Fixes for compiling with 64bit linux. Thanks KeyzerSuze.
retry.patch <- Work around for a bug in many getopt functions.
sc7.patch <- Fixes skipping in SC7.0.1, SC side patch already applied. Thanks Alan.
version.patch <- Updates SS version to 0.7.5.1, noting above 3 patches applied.

What problems other than the skipping are you seeing with the OSX version?

I have another patch which is needed to get SS to run properly on my older linux machine, but isn't needed with any current linux distro. Perhaps OSX needs it as well.


Ralphy

[pippin]

What problems other than the skipping are you seeing with the OSX version?


Keeps crashing quite frequently, especially after standby
-m parameter to set a MAC does not work (parsing error)
elapsed time has some issues: when you do pause and then restart playing elapsed time is reset to "0" although the track continues to play where it was
on streaming media, duration is not shown correctly

A lot of this does not look like a player issue yet it only happens with squeezeslave, never with SBx or SoftSqueeze

[ralphy]

Keeps crashing quite frequently, especially after standby
-m parameter to set a MAC does not work (parsing error)
elapsed time has some issues: when you do pause and then restart playing elapsed time is reset to "0" although the track continues to play where it was
on streaming media, duration is not shown correctly

A lot of this does not look like a player issue yet it only happens with squeezeslave, never with SBx or SoftSqueeze

Which version of squeezecenter are you running?

What is the full command line you are using to start squeezeslave?

[pippin]

Which version of squeezecenter are you running?

What is the full command line you are using to start squeezeslave?

7.0.1 (7.0 until a week ago or so, same symptoms)

CL (loop for crash failover):
while :; do DYLD_LIBRARY_PATH=/Applications/Utilities/SqueezeSlave /Applications/Utilities/SqueezeSlave/squeezeslave; done

The one with the -m parameter would have been plus:
-m 02:02:02:02:02 or -m02:02:02:02:02 or -m02%3A02%3A...

all don't do it.

[hickinbottoms]

pippin wrote:
> The one with the -m parameter would have been plus:
> -m 02:02:02:02:02 or -m02:02:02:02:02 or -m02%3A02%3A...
>
> all don't do it.
>
>

It's probably a typo - but did you mean five "02"s? There should be six
in a 48-bit MAC address.

Stuart

[pippin]

pippin wrote:
> The one with the -m parameter would have been plus:
> -m 02:02:02:02:02 or -m02:02:02:02:02 or -m02%3A02%3A...
>
> all don't do it.
>
>

It's probably a typo - but did you mean five "02"s? There should be six
in a 48-bit MAC address.

Stuart

Ooops.
That's it.
Thanks.
My bad.
I just copied the ID SqSl had in the logs and changed it, and that had only five pairs...

And then there's only five fingers and I need the other hand for typing...

[ralphy]

Ooops.
That's it.
Thanks.
My bad.
I just copied the ID SqSl had in the logs and changed it, and that had only five pairs...

And then there's only five fingers and I need the other hand for typing...

Did you rebuild with the patches I posted?

Once you have can you also try adding;

-r 15 -s

before the -m on the command line.

That will cause squeezeslave to retry every 15 seconds if it looses the network connection to Squeezecenter. If you don't specify the retry option squeezeslave exits on a lost connection. Which might explain the crashes you've been seeing.

The -s disables any further keyboard input being read and waits for a SIGTERM signal before exiting.

Ralphy

[pippin]

Did you rebuild with the patches I posted?

Once you have can you also try adding;

-r 15 -s

before the -m on the command line.

That will cause squeezeslave to retry every 15 seconds if it looses the network connection to Squeezecenter. If you don't specify the retry option squeezeslave exits on a lost connection. Which might explain the crashes you've been seeing.

The -s disables any further keyboard input being read and waits for a SIGTERM signal before exiting.

Ralphy

No, I haven't built it myself, yet. I got lost with all the additional stuff I would have needed to do so. I'm still a bit new to the Mac and all I've used so far is XCode so whatever is not within there is too much for me, I also currently have other priorities.

I will contact Wout Mertens, who did the original build, though. Maybe he's already reading this...

[ralphy]

The following squeezeslave binaries are now available on sourceforge;

linux i386
linux AMD64
solaris 10 i386
solaris 9 sparc (also tested on solaris 10)
win32 i386

https://sourceforge.net/project/showfiles.php?group_id=105169&package_id=176494&release_id=532275

Version 0.7.5.1 works with SqueezeCenter v7.0.1

Ralphy.

[nitters]

I've managed to install squeezeslave on my asus wl500gp running openwrt, with logitech USB speakers. "a poor man's squeezebox" :)

The software volume control doesn't work - it completely garbles the sound. However with -v on, the USB speakers handle the volume control OK.

It runs OK - though I sometimes get "random" audg messages that seem to mess up the output. Again - the sound gets completely garbled - same as I'm experiencing with the software volume control. I was looking for an option to turn off the replay-gain, but it doesn't seem to be available for a squeezeslave player in the squeezecenter options (it is there for the SB receiver and SB3). Does anyone know how to turn this off for a squeezeslave player ?

Thanks,
Mark

[nitters]

Actually - how come this replay gain option has any effect if I'm using the hardware volume control ? Is it implemented using the software volume control, regardles of the "-v" setting ?

[ralphy]

I was looking for an option to turn off the replay-gain, but it doesn't seem to be available for a squeezeslave player in the squeezecenter options (it is there for the SB receiver and SB3). Does anyone know how to turn this off for a squeezeslave player ?

Thanks,
Mark

Adding the --oldplayer (-O) option when starting squeezeslave should to the trick.

That's a capital letter O not zero.

You'll then be able to change all the player setttings in Squeezecenter just like the other players.

Ralphy