PDA

View Full Version : Squeezebox radio too loud



christhedon
2009-11-03, 12:54
Hi,

I have the squeezebox radio and two squeezebox receivers. With the amps attached to the receivers I have the volume up quite high, so that when I walk from room to room the volume level is similar. However the squeezebox radio volume is just one setting (i.e. the one you use for syncing) so it is much louder than the other amps at the same synced volume level. Is there a way to turn down the internal squeezebox radio volume so that all the systems have the same volume?? With one of my amps the volume is high enough as it is such that I don't really want to turn it up anymore because when I switch sources it may well just blow the speakers...

Thanks in advance,

Chris

christhedon
2009-11-05, 06:18
Any ideas on this. As it stands its make the system cumbersome.

aubuti
2009-11-05, 07:06
Don't sync the volume controls on the different players? That's easy for me to say because while I often sync players I've always preferred localized control of the volume in each room. Just because it's too loud in kitchen doesn't mean it's too loud outside. Your needs/preferences may differ.

Other than that there may be an existing enhancement request for sync'd volume but at different levels (ie, volume goes up and down together, but from a variable base level). You can search for it on bugs.slimdevices.com and add your vote and comments there to try to get it implemented in a future release. If there isn't one you can create it.

christhedon
2009-11-05, 14:14
I have the "sync volume" option enabled and want both devices to synchronously change volume so if he turns down one the other will go down, too.
Just like with the Sonos.
Now with SB you can only adjust the absolute volume level and on the Radio you have no other preamp to change gain in between. So if you can't find a setting where "50%" and "25%" is likely acceptable on both devices, you are in trouble.
I see the same, that's why Sonos and iPeng have that feature to have a "Master" volume that changes the volume on all devices but you can still make relative adjustments for single players.

aubuti
2009-11-05, 14:22
Yes, I understand all that. I suggest you add your data and vote to the enhancement request, or if one does not already exist, then create one. Items in bugs.slimdevices.com get more systematic attention from the developers than forum posts do.

christhedon
2009-11-06, 11:32
I have the "sync volume" option enabled and want both devices to synchronously change volume so if he turns down one the other will go down, too.
Just like with the Sonos.
Now with SB you can only adjust the absolute volume level and on the Radio you have no other preamp to change gain in between. So if you can't find a setting where "50%" and "25%" is likely acceptable on both devices, you are in trouble.
That's why Sonos and iPeng have that feature to have a "Master" volume that changes the volume on all devices but you can still make relative adjustments for single players.


I'll set-up an account and I'll post the above with the subject "Need a sync volume control and a seperate volume control for all squeezebox devices"

Would that be clear enough do you think?

Thanks,

Chris

Mnyb
2009-11-06, 12:36
Do that and I vote on it directly, or point me to an existing bug for this.

This is another completely obvious feature that does not exist in sc/ss/sbs , should have been there the exact same moment as sync was introduced.
I guess i had this system so long that i got used to most of its quirks.

Some times it's very refreshing with post with another perspective.

pippin
2009-11-06, 13:13
I'll set-up an account and I'll post the above with the subject "Need a sync volume control and a seperate volume control for all squeezebox devices"

Would that be clear enough do you think?

Thanks,

Chris

C'mon. There is already a bug on this and I did already post the link in that other thread.
https://bugs.slimdevices.com/show_bug.cgi?id=15011

christhedon
2009-11-08, 10:09
I'm not sure your post is as well worded and clear as the one I was going to post (PS I lifted it from some other forum so its not my words).
I'll vote on it anyway, if it doesn't get attention soon, maybe open a new bug??

christhedon
2009-11-08, 10:19
mynb - vote for this maybe.

https://bugs.slimdevices.com/show_bug.cgi?id=15011

Let me know if you think I should post a new one.

aubuti
2009-11-08, 19:50
I'm not sure your post is as well worded and clear as the one I was going to post (PS I lifted it from some other forum so its not my words).
I'll vote on it anyway, if it doesn't get attention soon, maybe open a new bug??
In my experience opening a new bug for the same - or even closely related - bug/enhancement rq is not a good strategy. It will likely get flagged as a duplicate and then marked up with strikethrough (effectively deleted, even though the post is still there for the record). If you didn't think the initial post was well worded then you can add your own comment. That's how these things get focused, refined, and in some cases eventually implemented.

jrichardson
2009-11-11, 15:55
mynb - vote for this maybe.

https://bugs.slimdevices.com/show_bug.cgi?id=15011

Let me know if you think I should post a new one.

Please just keep the 1 bug focused on what you want, and have people vote for it :)

Feel free at add your comments to the bug, if you feel it's on topic

christhedon
2009-11-15, 03:56
I got to say I think its a pretty poor show not having two volume controls like the sonos. We really shouldn't have to raise a bug for this. It highlights a possible lack of use case testing on these products. I've bought the radio but I just don't use it. I think I'll search for people having issues syncing it to their squeezebox receivers.

pippin
2009-11-15, 05:06
Well, don't want to be too pushy, but you COULD get yourself an iPod touch with iPeng :)

christhedon
2009-11-19, 13:08
:)

Yeah everytime something doesn't work as it should buy something else to integrate with it that will make it work! That would make a lot of companies happy!! :)

Anyway what is more annoying with this is that you can't say don't sync volume if you have three devices. If you say on the radio don't sync volume then it wno't go up and down when the other two devices go up and down. But if you move the volume up and down on the radio the other two devices go up and down. Only other solution is no syncing of volume on any devices! which is not a solution for me.

Still getting audio sync issues as well between the radio and other devices.

Not ecstatic about this purchase to be honest.

christhedon
2009-11-29, 08:51
Where do you go to see if they are going to implement this "feature" or not? (Feature in quotes because it is a feature but really should have been there from the outset - its a bit of a dissapointment)

aubuti
2009-11-29, 09:57
Where do you go to see if they are going to implement this "feature" or not? (Feature in quotes because it is a feature but really should have been there from the outset - its a bit of a dissapointment)
You can follow the bug/enhancement request at http://bugs.slimdevices.com/, but that won't tell you a definitive policy statement of will/won't implement while development is still in process. It will give you an idea of the priority it is being accorded and how much activity there is, and if/when it is ultimately resolved or abandoned.

mlsstl
2009-11-29, 11:27
christhedon wrote: "I got to say I think its a pretty poor show not having two volume controls like the sonos. We really shouldn't have to raise a bug for this. It highlights a possible lack of use case testing on these products. I've bought the radio but I just don't use it. I think I'll search for people having issues syncing it to their squeezebox receivers."

It is sometimes easy to forget that a really important feature for ourselves may not be a big deal for a large percentage of other users.

Sonos targeted the multi-room system from the beginning (it even states that in large type on their web site header) so it makes sense this was a priority for them at the start.

Like a lot of people, I started with a SliMP3 many years ago as a dedicated music source on one system. Though I have three current Squeeze devices now, I use them in separate systems and have only experimented with synching out of curiosity. It just isn't the way I - and I suspect many others - listen to music.

Most products are similar. They cater first to the largest segment of their market and then add other features later.

Your idea is a good one, and it would strike me as reasonably feasible, but I suspect that it'll take some serious programming time. Where that fits into the developers big list of what to do when, I'm not sure.

If you can't wait on this, I'm sure Sonos will be happy to take your money right now. ;-)

christhedon
2009-11-29, 11:29
It has only had 7 votes which leads me to. I don't like the idea of this not being implemented purely because the subset of people that use and understand their bug site are not voting for a post they might not have seen. It should have been a use case test in the first place and been implemented before the products hit the market.

Thanks,

Chris

christhedon
2009-11-29, 11:45
It is sometimes easy to forget that a really important feature for ourselves may not be a big deal for a large percentage of other users.

Sonos targeted the multi-room system from the beginning (it even states that in large type on their web site header) so it makes sense this was a priority for them at the start.

Like a lot of people, I started with a SliMP3 many years ago as a dedicated music source on one system. Though I have three current Squeeze devices now, I use them in separate systems and have only experimented with synching out of curiosity. It just isn't the way I - and I suspect many others - listen to music.

Most products are similar. They cater first to the largest segment of their market and then add other features later.

Your idea is a good one, and it would strike me as reasonably feasible, but I suspect that it'll take some serious programming time. Where that fits into the developers big list of what to do when, I'm not sure.

If you can't wait on this, I'm sure Sonos will be happy to take your money right now. ;-)

Just saw this after my last post. Maybe you're right and many people aren't using the syncing feature, but I haven't seen the statistics. I believe in the future that more people will use syncing for music around the home, but I'm not an oracle. From the outside I would say Sonos are in a similar market, and squeezebox could have just simply looked at Sonos usability and asked why do they do that and do it if it fits their goals and don't if it doesn't. As it stands I don't know whether this was already thought of by squeeze box guys and dimissed or whether they simply missed it and don't care, or whether they missed it and wished they didn't. But if you're right and not many people using it now and I'm wrong and not many people will use it then they will not have much incentive to change it. I'm hoping you're wrong and I'm right, and that that becomes apparent (although 7 votes is bit rubbish so even if you're wrong and I'm right we may never know) because I have an incentive for them to implement it so I can use my squeezebox radio properly.


RE: the software, I would have thought it would have been easy to implement something where you change the volume property on each device object to take in two other volume properties and calculate a volume based on that, but then I haven't looked at their source code.
Cheers,

Chris

mlsstl
2009-11-29, 13:44
christhedon wrote: "I'm hoping you're wrong and I'm right,"

I'm not particularly concerned one way or the other as to whether I'm right or wrong. I was just trying to add a perspective to the conversation that perhaps you hadn't considered.

Probably every product I've ever bought, from a car to a dishwasher, has been missing a feature or two that I liked (or was better implemented) in a competitor's version. However, when I looked at the overall picture, I chose the one I bought in spite of whatever I thought was a deficiency.

It would be pleasant to have the extra measure of control you advocate in a whole-house system, but it is not all that important to me. I rarely listen to music as background, wanting it to follow me from room to room as I move about the house. I don't throw parties where music is needed everywhere (in fact it is nice to be able to get away from it at some events.)

However, that is just me. Other people would prefer something different as you've illustrated so well.

As for the difficulty of programming, that is for others to decide. I know the few projects I've done over the years have sometimes left me wishing I'd made an allowance for this item or that in the very early stages. However, if it easy, I suspect you'll get your wish. If it is more complicated for whatever reason, maybe it'll still show up eventually.

Good luck and hope it works out for you.

jdoering
2009-11-29, 14:17
Don't the Boom and Radio have volume curves tweaked to their use-cases (more sensitive at the low end)? If other squeezeboxes don't use the same curves isn't global volume control with per player offsets more complicated? I'm not saying infeasible; I'm just wondering if an obvious implementation that doesn't account for individual device would actually produce the desired result across the volume range.

I wonder how iPeng implements it?

I voted for the bug but I agree that it's pretty convoluted request that didn't even start focused on volume. Doesn't look like a good way to track a very specific technical sync feature request IMO. UI is an afterthought on this (versus power control, etc). Maybe that's how you avoid per device volume issues. You don't sync the volumes of the devices at all. Leave them as local control. Instead it is more about on-the-fly adjustment of the baseline level of the stream. Like replay-gain; but adjustable midstream. Way in over my head at this point... but it seem like that would eliminate the need for the central algorithm to care about how individual devices control volume.

-Jeff

aubuti
2009-11-29, 14:39
Just saw this after my last post. Maybe you're right and many people aren't using the syncing feature, but I haven't seen the statistics. I believe in the future that more people will use syncing for music around the home, but I'm not an oracle.
I don't think you mean to, but it seems here like you're conflating the sync feature with the more specific issue of sync'ing relative volume levels of sync'd players. I think a lot of people use sync, but only a subset of that group feel the need for the feature you seek. I have no idea how big that subset is. My guess is it's a minority of those who use sync, but that's just a guess. I regularly sync my players, but I *prefer* to control each player's volume separately. You have different preferences and that's fine. But don't assume that because other people aren't enthusiastic about this feature that they're not using sync.

If it's really important to you, I don't see why you don't get the cheapest iPod Touch and iPeng.

peterw
2009-11-29, 17:50
I don't think you mean to, but it seems here like you're conflating the sync feature with the more specific issue of sync'ing relative volume levels of sync'd players. I think a lot of people use sync, but only a subset of that group feel the need for the feature you seek.

And I think most Squeezebox owners (sadly) don't even own two Squeezeboxes.

The trouble here is mainly one of user interface. It's simple if you always only change the "local" volume (as SC/SBS do now), or if you always change all synced players' volumes. But how do you -- within the confines of the Boom, Classic, and Controller buttons & screens -- give users the choice of either changing the volume on all synced players or only the local player? Offering both local and group volumes are easy with touchscreens as on SB Touch and iPod Touch, but not so easy when you have simpler screens and dedicated volume buttons.

I've thought about adding group volume control to SyncOptions, but the biggest problems are motivation (in years of owning multiple Squeezeboxes, this is a feature I've seldom wished for) and the user interface question. But maybe I'm wrong about the UI; maybe some folks here really would like volume control to always affect all synced players. Is that right?? You'd never want to only adjust the "local" volume?

pippin
2009-11-30, 06:41
I don't think you mean to, but it seems here like you're conflating the sync feature with the more specific issue of sync'ing relative volume levels of sync'd players. I think a lot of people use sync, but only a subset of that group feel the need for the feature you seek. I have no idea how big that subset is. My guess is it's a minority of those who use sync, but that's just a guess. I regularly sync my players, but I *prefer* to control each player's volume separately. You have different preferences and that's fine. But don't assume that because other people aren't enthusiastic about this feature that they're not using sync.

If it's really important to you, I don't see why you don't get the cheapest iPod Touch and iPeng.

I believe it's one of those features where many people simply don't comment a lot about.

It's kind of interesting because this was one of the most heavily debated items during the beta test phase of iPeng 1.2, while some people actually requested that feature others opposed it heavily and suggested it not to become the default.
It now _is_ the default and I really did not have a _single_ question about that, and I do get quite a lot of usability questions, especially for things that are not explained in the tutorial animations (this one isn't).

So my impression is that it actually fits quite well with what most people expect the main volume control to do for synced players.

radish
2009-11-30, 11:08
In any case, I would have thought it would be pretty easy to implement as a plugin, no? Either for SBS or as an applet for the SBC (similar to iPeng). Another option besides waiting for it to be added to the core.

pippin
2009-11-30, 11:49
Hard to do as an applet on SBC. You would have to recreate all the server comms separate from the applet logic because SBC only talks to one player client object.
It was easy in iPeng because iPeng did already operate on all players.

peterw
2009-11-30, 11:54
In any case, I would have thought it would be pretty easy to implement as a plugin, no?

See my last comment. If there's no easy way to switch between "local" and "group" volume, then, yes. I just don't imagine anyone would want it to be difficult to change only the local player's volume.

pippin
2009-11-30, 12:01
In any case, I would have thought it would be pretty easy to implement as a plugin, no?

See my last comment. If there's no easy way to switch between "local" and "group" volume, then, yes. I just don't imagine anyone would want it to be difficult to change only the local player's volume.
You could use the normal volume controls on the SBC for master volume and have a context menu shortcut (volume-hold?) to bring up a selection of players where you display an individual volume control for each player.
Jive even allows you to override the volume buttons in that menu.
From a plugin this should be more simple because it has access to all players.

peterw
2009-11-30, 18:07
You could use the normal volume controls ... for master volume and have a context menu shortcut (volume-hold?) to bring up a selection of players where you display an individual volume control for each player.


Volume-hold won't work since that means change volume quickly, but that's a nice idea for an ip3k UI using my ContextMenu plugin. I wouldn't bother with a Jive UI, as my understanding of the core/jive context menu in 7.4 is that it's too dumb/primitive (iiuc, 7.4 jive context menus depend on line-items, not player state).
.
Danke!

pippin
2009-11-30, 23:55
Volume-hold won't work since that means change volume quickly, but that's a nice idea for an ip3k UI using my ContextMenu plugin. I wouldn't bother with a Jive UI, as my understanding of the core/jive context menu in 7.4 is that it's too dumb/primitive (iiuc, 7.4 jive context menus depend on line-items, not player state).
.
Danke!

OK, didn't know that with the volume-hold, don't use the controller very often.
I didn't mean to say it really has to be 7.4's context menu functionality, probably bad wording. What I meant was that you could bring up a menu with the items

Volume Player 1
Volume Player 2
...

And if you select one of those, a volume control slider comes up.
Unfortunately you can't embed a slider directly into a menu like in iPeng, AFAIK.

Would need some other key, though...

peterw
2009-12-03, 21:12
Unfortunately you can't embed a slider directly into a menu like in iPeng, AFAIK.

I hear that! SB Touch should seize this opportunity to make the gear more zone/sync-friendly. Here's a UI suggestion for Radio: press the volume knob (which in 7.4 toggles the mute state) and get a screen like


Volume for synced players
xxxxxxxxxx---------------
Volume for this player
xxxxxxxxxxxxxx-----------
Volume for Den
xxxxxxx------------------
Volume for Kitchen
xxxxxxxx-----------------


Use the nav wheel to select a line, and the volume knob to change the volume of the selected line. Mute is toggled by pressing a knob while a line is highlighted, so you could easily mute any or all players. Use three different colors for the volume indicators: one for the whole sync group, one for the local player, and the other color for each of the other players. Let users decide whether simple volume knob turns (i.e., using the volume knob on any other screen) control local or all synced players' volumes. If the knob normally controlled the whole sync group, the first line should be "Volume for synced players". So your typical volume control would just require turning the volume knob, and the other normal case would require you to tap the volume knob once to bring up the special screen, nav down once, and then use the volume knob. Muting whatever the volume knob normally controls would require two taps. The "Volume for synced players" indicator would show the average volume of all players in the sync group.

This should be very doable in an applet. Any takers?

peterw
2009-12-24, 14:45
Any ideas on this. As it stands its make the system cumbersome.

You could try my SyncOptions plugin version 2.1.30 or newer from my test repository, http://www.tux.org/~peterw/slim/slim7/repodata-test.xml. This version adds a new option, "relative volume sync". To use it, do NOT set the core synchronize volume option, but enable the SyncOptions "relative volume synchronization" option. As you change volume on any given player, SyncOptions will make proportionate volume changes on the others it's synced with.

There's an additional setting you can tweak -- how many seconds to wait after joining a sync group before volume changes affect all players. Imagine you have Player A and Player B synced, and then you make Player C join that sync group. This user-configurable delay time gives you as many seconds as you'd like to tweak Player C's volume without affecting the volume on A or B, as C is likely to be either too quiet or too loud when it first joins the sync group. After the specified delay, you should see a message on the player or Controller display reminding you that any volume change from that point on will affect all players in that sync group.

Please let me know what you think of it. I've tested it a bit on a 7.3 system but not on a 7.4 system with Radio (laziness, sorry).

-Peter

pippin
2009-12-24, 15:54
What's the algorithm you use for the proportional changes? I found simple proportional volume change to be a bit problematic for extreme values so here's what iPeng does:
1. Extend volume range beyond 100 to avoid cliping for loud players. So interally it will handle volumes >100 for individual players and then just clip for the CLI command
2. It generates a relative change, e.g. original volume times 1.1 for a change of 10% on the slider. This is for each player.
3 generate an absolute volume change for each player. So if the handle is being moved 10% this translates into a 10 tick change no matter where the volume is at.
4. Build an average (straight one) betwen 2+3. This is the new volume for each player.

This ensures you font get stuck at 0 volumes and you don't lose proportionality when a player runs into high volume clipping. Plus it somewhat compensates for the nonlinearity of the volume ramps. I really like the result.

peterw
2009-12-24, 22:27
Pippin, thanks for sharing your algorithm. Mine's a straighforward linear/proportional model based on the N/100 volume level -- when a player joins a sync group, I note each player's volume. When any volume changes, I calculate the new / original ratio, calculate new volumes for sync peers, and change their volumes if needed.

If any player would go over 100, I refresh my "orginal" volumes. That's the best I came up with to deal with this use case: A at 40, B at 60. A jumps to full volume. B should go to 150, but that's impossible, so B goes to 100, also. Now somebody decreases the volume of B to 95. What happens to A?

If I had treated B as having a relative synced volume of 150, then switching to 95 would be a ~34% decrease. Even with your model, as I understand it, you'd average -34% and -5% and decide to decrease A by about 20 clicks just because B became a little bit quieter.

The tradeoff for my model of recalculating when any peer hits 100 is that if you really turn the volume up, you end up with the players pretty much back at the old Logitech model of each player having exactly the same volume. But I rarely crank any player to full volume, so this is a tradeoff I'm not too worried about.

What I have now certainly isn't perfect (and I just realized there's probably a bug in how it handles a player joining an existing sync group if the existing sync group has already taken advantage of the relative volume sync), but I do find myself appreciating it more than I expected when I'm syncing players in adjacent rooms.

pippin
2009-12-25, 01:24
If I had treated B as having a relative synced volume of 150, then switching to 95 would be a ~34% decrease. Even with your model, as I understand it, you'd average -34% and -5% and decide to decrease A by about 20 clicks just because B became a little bit quieter.

Ah, no.
I have a bit of a different use case in that I have two volume controls, one master and one individual. Whenever you change an individual volume only the volume of that player changes and the averages are recalculated.
If you move the master volume, the relative volume changes stay consistens for all players that haven't reached min/max.


The tradeoff for my model of recalculating when any peer hits 100 is that if you really turn the volume up, you end up with the players pretty much back at the old Logitech model of each player having exactly the same volume. But I rarely crank any player to full volume, so this is a tradeoff I'm not too worried about.

No, the MAIN tradeoff of your system is that one a player you are controlling indirectly gets to 0 it gets stuck there.


but I do find myself appreciating it more than I expected when I'm syncing players in adjacent rooms.

I can believe this. Since I implemented this in iPeng I use nothing else. It's especially good for my kitchen Radio and Living Room Transporter since the Transporter is usually around or above 50% and the Radio would just be too loud for that (original thread title).

Now the one other thing I came to like: Joined power control. Same thing: I still need the individual capability because that's how I turn on/off single players in a sync group if I want to keep a room silent (which is what I do almost all of the time: no need to keep the bathroom playing all day, but I want it to join when I take a shower).
But it's just so cool to leave your home and turn off all your players with a single click on the power button on your phone while you step out of the door :)

peterw
2009-12-25, 06:34
Ah, no.
I have a bit of a different use case in that I have two volume controls, one master and one individual. Whenever you change an individual volume only the volume of that player changes and the averages are recalculated.
If you move the master volume, the relative volume changes stay consistens for all players that haven't reached min/max.


Ah. What happens if you try to use the master volume in my A=40, B=60 scenario to turn A to max volume? Does A stop somewhere around 60 or 70 unless you use its individual slider?


No, the MAIN tradeoff of your system is that one a player you are controlling indirectly gets to 0 it gets stuck there.

I don't see that. If you turn A or B to 0 in my scenario, they still have the same "original" volumes. Turn A to 0 and both do go to 0, but if you then increase A to 10, B would go to 15 (new A volume 10 / original A volume 40 * original B volume 60 = new B volume 15). While my first algorithm did have a stuck-at-zero flaw, that algorithm never left my laptop! (Actually there is a way to get stuck-at-zero still, but only if Player C joins the group while A and B are at 0, or close to it. I see how your algorithm would help in that case.)


Now the one other thing I came to like: Joined power control. ... it's just so cool to leave your home and turn off all your players with a single click on the power button on your phone while you step out of the door :)

One of these days I'll commit to a fancy new phone that'll double my montly bill (no, I'm not tempted by iPod Touch). Until then, I can only envy all of you with fancy Unix-based touchscreen smart-phones.

pippin
2009-12-25, 11:09
Ah. What happens if you try to use the master volume in my A=40, B=60 scenario to turn A to max volume? Does A stop somewhere around 60 or 70 unless you use its individual slider?

Well, as I said, my master volume is separate and would thus show "50" in your scenario. If I turn it up, A will reach 100% later than B but both eventually will. If I turn it back down, B will start to turn the volume down later than A.


I don't see that.

Yea, I got that wrong. You keep the original relative factor between the players constant and multiply the change with this, don't you?
I can't do something like that because I can't preserve a state forever, if you quit the App the relative states are lost and there's little sense in storing them since they could get changed from outside iPeng. BTW they can also get changed from outside iPeng while it's still running.


One of these days I'll commit to a fancy new phone that'll double my montly bill (no, I'm not tempted by iPod Touch). Until then, I can only envy all of you with fancy Unix-based touchscreen smart-phones.

I churned out a lot of cache and bought a lock-free one from Italy (the have to sell them that way there) and so could keep my monthly bill where it is.

peterw
2009-12-26, 07:47
You keep the original relative factor between the players constant and multiply the change with this, don't you?
Yes, right. SyncOptions hooks itself into SBS so it's aware of every sync/unsync and volume change, so this is not bad at all.


I can't do something like that because I can't preserve a state forever, if you quit the App the relative states are lost and there's little sense in storing them since they could get changed from outside iPeng.

Ah, of course.

Is there a way my plugin could tell if it was iPeng that was changing the volume? It wouldn't make any sense for SyncOptions to do relative volume syncing if the user is using a controller like iPeng that handles that already and already has a way to explicitly change one player's volume, but I could see SyncOptions users wanting relative volume changes if they turned the knob on a Radio or Boom. With SBS 7.4, the mixer volume CLI command supports tags (SqueezePlay/Radio/Touch use them), so it's conceivable that iPeng could add an "ipeng" tag...


I churned out a lot of cache and bought a lock-free one from Italy (the have to sell them that way there) and so could keep my monthly bill where it is.

Funny, I only learned of the unlocked Euro iPhones a week after I was in France (first trip from the US to Europe in a while). Just as well, though, as word is that Orange France sells iPhones that are only unlocked enough to accept other French SIM cards. :-/

pippin
2009-12-26, 11:37
Is there a way my plugin could tell if it was iPeng that was changing the volume? It wouldn't make any sense for SyncOptions to do relative volume syncing if the user is using a controller like iPeng that handles that already and already has a way to explicitly change one player's volume, but I could see SyncOptions users wanting relative volume changes if they turned the knob on a Radio or Boom. With SBS 7.4, the mixer volume CLI command supports tags (SqueezePlay/Radio/Touch use them), so it's conceivable that iPeng could add an "ipeng" tag...

sounds reasonable.
How does this work, didn't find anything in the CLI doc


miver volume 95 tags:ipeng

Funny, I only learned of the unlocked Euro iPhones a week after I was in France (first trip from the US to Europe in a while). Just as well, though, as word is that Orange France sells iPhones that are only unlocked enough to accept other French SIM cards. :-/[/QUOTE]
Hm. My Italian one (a 3G) works fine with German SIM cards. Actually I don't remember who that Italian provider was.

peterw
2009-12-26, 12:01
sounds reasonable.
How does this work, didn't find anything in the CLI doc


miver volume 95 tags:ipeng


Yeah, SqueezePlay in 7.4 uses "seq" tags, I think to help deal with any contention between local and server-based volume changes (Radio's volume knob changes its volume immediately and notifies SBS after the fact). I think it should be



mixer volume 95 ipeng:1


I'll get back to you when I get that figured out and tested. Thanks for considering the change!

pippin
2009-12-26, 12:42
Yeah, SqueezePlay in 7.4 uses "seq" tags, I think to help deal with any contention between local and server-based volume changes (Radio's volume knob changes its volume immediately and notifies SBS after the fact).

Out of curiosity: Do you know how THAT works? I could probably want to do something similar with iPeng's volume change (although you probably will not be able to change that remotely)


I'll get back to you when I get that figured out and tested. Thanks for considering the change!

Well, it makes a lot of sense to me.

peterw
2009-12-26, 17:44
Out of curiosity: Do you know how THAT works? I could probably want to do something similar with iPeng's volume change (although you probably will not be able to change that remotely)

It involves some client logic -- the seq_no (not seq) tag value is sent back to the client in a SlimProto command (this is from Squeezebox2.pm, which is used for SqueezePlay clients, too):


if (defined($client->sequenceNumber())) {
$data = pack('NNCCNNN', $oldGain, $oldGain, $dvc, $preamp, $newGain, $newGain, $client->sequenceNumber());
}
else {
$data = pack('NNCCNN', $oldGain, $oldGain, $dvc, $preamp, $newGain, $newGain);
}
$client->sendFrame('audg', \$data);



Well, it makes a lot of sense to me.

The CLI format 00:04:20:01:02:03 mixer volume 50 ipeng:1 worked as well as I could expect in 7.3 and 7.4 -- in 7.4 I see the tag and can respect it, but in 7.3 I cannot. I just pushed a new test version of SyncOptions that refuses to do relative volume sync for any CLI command with an "ipeng" tag with value "1".

Kuben72
2010-02-24, 12:26
Hi Peter. IPeng just told me that you have a testversion of SyncOptions that can sync volume control. just downloaded it and it works like a charm. Great plugin. When are you going to release it?

peterw
2010-02-24, 21:01
Hi Peter. IPeng just told me that you have a testversion of SyncOptions that can sync volume control. just downloaded it and it works like a charm. Great plugin. When are you going to release it?

Are you running 2.1.31? Honestly, I'd forgotten I even added this ipeng:1 tag support. If that's working for you, I'll re-release it as 2.2.0. Thanks for reminding me.

Kuben72
2010-02-25, 00:02
No problem. If you could wait a few days I will translate it to Danish and mail you the strings.txt file.

peterw
2010-02-25, 05:29
No problem. If you could wait a few days I will translate it to Danish and mail you the strings.txt file.

That would be great!

christhedon
2010-05-17, 14:09
Is the volume thing ever going to be implemented. Its annoying everytime I have all three of my systems running that when I turn down the volume in the lounge and bedroom the radio volume doesn't go down (because I can't sync them because if I do turning down the radio to 70 makes my other players very quiet)

Ikabob
2010-05-17, 14:23
Solution to this,I think: Get Ipeng on an Itouch. If you use that as your controller,you can lower each individual player alone or lower all the synced players in unison...you are in control. I would imagine the Logitech Controller could accomplish the same thing. Good luck.

aubuti
2010-05-17, 14:29
Is the volume thing ever going to be implemented. Its annoying everytime I have all three of my systems running that when I turn down the volume in the lounge and bedroom the radio volume doesn't go down (because I can't sync them because if I do turning down the radio to 70 makes my other players very quiet)
Did you see peterw's response to you about 5 months ago in post #33 of this thread? It's working with the SyncOptions plugin.

Or are you looking for a solution with mysqueezebox.com? I wouldn't hold my breath -- they have much bigger things on their plate with that.

christhedon
2010-05-17, 14:46
Yes I can switch between the players on the remote and change the volume. In fact this is what I do. However I can't tell whether the player in the other room is too loud until I walk into it. And its a little cumbersome.