philippe_44 wrote:
> So it might be that the only ip3k for which it does not work is the Boom
> then, right? I should make it a negative logic in that case
Yes, based on our testing I'd agree with that approach.
Ralphy
*1*-Touch, *5*-Classics, *3*-Booms, *2*-UE Radio
'Squeezebox client
frankd wrote:
> Hi Ralphy,
> I would be interested in patches for the radio and Touch for the
> official firmware. I tried the new firmware with one radio , however
> some patches I used in the past will not work with the new firmware,
> even when modifying the supported versions of the patches
philippe_44 wrote:
> Are you sure? I just traced that on my squeezelite-esp32 and the value
> I'm receiving is the gainL multiplied by a ratio of (25-Balance)/Balance
> (if balance is negative, negate it and apply that to gainR). Where are
> you tracing the gainL and gainR values from?
I
ralphy wrote:
> Yes, based on our testing I'd agree with that approach.
ok, I'll wait for somebody with a transporter and will do then
LMS 8.1.x on Odroid-C4 - *SqueezeAMP!*, 5xRadio, 5xBoom, 2xDuet,
1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000,
ShairPortW, 2xChromecast
Ron F. wrote:
> I possibly lack any understanding of what is going on here, so please
> forgive if that is the case...
>
> I assume a balance shift to the right channel is done with a positive
> balance number, and if that is true, it is being done by dropping the
> volume on the left channel?
philippe_44 wrote:
> No you are reading data correctly - per my previous post, it was me
I didn't realize you meant you made a mistake in the code. I just
thought you made a typo in the post.
--
Squeezebox apps for webOS, Android and Windows Phone,
http://www.angrygoatapps.com
philippe_44 wrote:
> You were obviously right. It's either time for me to retire or go back
> to school at grade < 5
Philippe, you need a rest, sleep, and a vacation! Your work has been
invaluable to all of us LMS users.
I need to learn Perl, so that some day maybe I can be of some help.
I just pulled the latest commit for LMS 8.2 which corrects the Balance
math, and I will test using my SBT player. I also just wrangled a
Transporter a few minutes ago, so I will test with that also.
*Living Room:* SB Touch + DIY PSU > CI Audio VDA.2 DAC + VAC.1 PSU >
VRX.1 cables > Emotiva
wt0 wrote:
> Yes I'm sure, I'm logging the raw values that I'm getting from the
> server. With volume set to 100 and a balance setting of 1, gainL is
> 1572864 and gainR is 65536. I even used Wireshark to sniff the network
> packets just to be sure. Here's hex dump + ascii from the audg
I just downloaded the latest LMS update, and the values look like they
are corrected. However, the gainL/gainR values are normally based on
the volume curve of the SB Boom so 0.96 gain is actually 52224 not
62914. I guess I could detect for balance changes and calculate the
gain differently
mherger wrote:
> > ok, I'll wait for somebody with a transporter and will do then
>
> I haven't been near my Transporter for months... it's in the office :-(
I'll assume it works as the other ip3k, except the Boom (for
understandable reasons). I've pushed an update that also correct my
grade
ok, I'll wait for somebody with a transporter and will do then
I haven't been near my Transporter for months... it's in the office :-(
___
discuss mailing list
discuss@lists.slimdevices.com
http://lists.slimdevices.com/mailman/listinfo/discuss
wt0 wrote:
> I'm not talking about what you see in the browser. I'm talking about
> what the player actually receives from server. I'm trying to add
> balance support to SB Player and noticed that when the balance is not
> zero, the gain value of the "audg" command of one of the channels is
frankd wrote:
> Hi Ralphy,
> I would be interested in patches for the radio and Touch for the
> official firmware. I tried the new firmware with one radio , however
> some patches I used in the past will not work with the new firmware,
> even when modifying the supported versions of the patches
wt0 wrote:
> I'm not saying that the ratio matters, 25 is fine. It's the values that
> are being sent by the server do not increase or decrease in a linear
> manner. They follow the progression of that list of numbers and there
> are 101 values. So, for example, it you set the volume to 96,
Philippe, your mistake is one that anybody could have made, anybody,
easy to do. It is NOT a big deal whatsoever!
Things like this happen all the time. When you commit code, we are your
QA/Testing department, and we love to do it!
I remember one of my Lockheed stories, about somebody driving
wt0 wrote:
> I didn't realize you meant you made a mistake in the code. I just
> thought you made a typo in the post.
No and this is what is sad: I just code something stupid and happily
wrote the same...
wt0 wrote:
> I just downloaded the latest LMS update, and the values look like they
>
You should convert gainL/gainR to and integer using the table, apply the
gain adjustment to that value then use it as the index in the table to
find to correct fixed point value.
So for lets say volume is set to 96 and balance is 5, gainL would be
52224 and gain adjustment would be (25-5)/25 =
philippe_44 wrote:
> No and this is what is sad and embarassing: I just coded something
> stupid and happily wrote the same... as said, I'll probably stop for a
> while
>
Philippe, I don't want to make light of your distress. I sort of
understand, even though I'm not capable of doing the
philippe_44 wrote:
> No and this is what is sad and embarassing: I just coded something
> stupid and happily wrote the same... as said, I'll probably stop for a
> while
>
>
> I just went for the simplest (or stupidest) but I think this does not
> matter much. The span of 25 is very arbitrary
philippe_44 wrote:
> ok, I'll wait for somebody with a transporter to confirm and will do
> then
I have a Transporter. Balance is working.
BTW, what is ip3k?
--
Squeezebox apps for webOS, Android and Windows Phone,
http://www.angrygoatapps.com
Ron F. wrote:
> Philippe, your mistake is one that anybody could have made, anybody,
> easy to do. It is NOT a big deal whatsoever!
>
> Things like this happen all the time. When you commit code, we are your
> QA/Testing department, and we love to do it!
>
> I remember one of my "company
I think the server side implementation of balance for SqueezePlay
players is broken. When I added "Balance=1" to SB Player's HELO string,
the balance slider shows up in Player -> Audio. However when I adjust
the slider, the gainL/gainR values SB Player gets for the channel that
should be
philippe_44 wrote:
> I'm probably thick again but then I don't think this is the right thing
> to do then. The 0..100 to 16 bits is not tabulated but interpolated
> using parameters that are defined by squeezebox2.pm or its descendants
> (e.g. squeezeplay.pm and boom.pm define it differently).
wt0 wrote:
> I think the server side implementation of balance for SqueezePlay
> players is broken. When I added "Balance=1" to SB Player's HELO string,
> the balance slider shows up in Player -> Audio. However when I adjust
> the slider, the gainL/gainR values SB Player gets for the channel
wt0 wrote:
> I think the server side implementation of balance for SqueezePlay
> players is broken. When I added "Balance=1" to SB Player's HELO string,
> the balance slider shows up in Player -> Audio. However when I adjust
> the slider, the gainL/gainR values SB Player gets for the channel
philippe_44 wrote:
> Good, so per my previous message, I have a PR ready for
>
> - duet (model:receiver) => balance
> - controller (model:controller) => balance
> - touch (model:fab4) => balance
> - radio (model:baby) => balance (works with headsets)
> - other squeezeplay : if capabilities
I don't think it will make much difference because the Slim network
protocol includes a discovery and advertising mechanism that allows
Squeezebox components to recognize each other in milliseconds. Depending
on your network topology you are however likely to benefit from
assigning a static IP
ralphy wrote:
> The current released balance feature has been working fine with
> squeezeplay for me.
>
> Full left is -25 and full right is +25. Browser cache perhaps?
>
> When you click apply does the balance change in squeezeplay?
>
> I have 'new MacOS Intel and Windows squeezeplay
Attached is full scanner log as you requested, thanks.
Try to fetch http://localhost:10002/api/songs?extended from your
MusicIP. Compare this with the list of files reported in the server.log
file. If the order is the same, you should find out which one was the
file to import on which LMS
wt0 wrote:
> I'm not talking about what you see in the browser. I'm talking about
> what the player actually receives from server. I'm trying to add
> balance support to SB Player and noticed that when the balance is not
> zero, the gain value of the "audg" command of one of the channels is
ralphy wrote:
> That's great. To keep the jive based players consistant I won't include
> the Balance capability in the next community firmware release and let
> LMS handle it.
>
> I noticed that the SB Classic in not in the list. I just tested one of
> mine and balance works with it as
ralphy wrote:
> Yes the touch can support the Balance feature, not sure about the ip3k
> players like the transporter.
>
> I have been testing it with Squeezeplay and on a touch with the
> community firmware. Balance support has already been added to my
> squeezeplay and community firmware
mherger wrote:
> You'll need to provide a bit more information to get some help. Enable
> logging for plugin.musicip, then provide the full scanner.log.
Attached is full scanner log as you requested, thanks.
+---+
|Filename:
34 matches
Mail list logo
