The volume control using lookups is not working right with the fishbone skin. In fact it seems to mute the MVP for certain but not all volume levels. With mvpmc 0.2.0 it's working perfectly. What could be the reason. Seems that the lookup table has no match for certain volume levels that are been sent from slimserver. Help please, because the fishbone skin rocks!! :O)
Sorry, but what's a fishbone skin.
Also, if you telnet to 9090 on the slimserver machine and type "listen 1", you can see what is being sent out by the slimserver program. Then you can compare between "normal" and "fishy" modes (i.e. see what values are being send out for controlling the volume) ;-).
Fishbone is just the name of the skin...
For whatever reason telnet is not working on the machine, but I guess the major difference between this skin and the default one is, that the granularity of volume control is diffrent. Default skin has volume levels between 0 and 100 with steps of 10 units I guess. The "fishbone" skin has 16 or 17 levels with values that does not match this pattern. As I looked to the mclient.c I had the opinion that the volume function watches out for an exact and not for a nearest match to its lokkup table. And this exact match cannot be found with the values send by the fishbone skin. What I do not understand is, that I thought volume should be sent to max level if no match has been found, but this is obviously not happening!!
Telnet might not be allowed by default on your Linux distribution (on windoze you're on your own). It's usually considered a security problem.
This might be obvious to you but I am still in the dark. So, is fishbone a Slimserver web page skin, a Softsqueeze skin or are you somehow skinning the graphic VFD on a Slimp3 box?
As for MClinet volume. I tried to use an equation, which would probably solved your problem, to fix the relation between Slimserver and the MediaMVP / IBM chip (I think one is linear and the other logarithmic). But, it never sounded the same as the other MVPMC applications. That and there really is no math library in this project. Someone suggested a look up table and it turned out to be simple, easy and adjustable.
I think the simple solution would be to change line 640 in mclient_mvpmc.c from:
while ((volume_server[i] != vol_server) & (i <= 40))
while ((volume_server[i] <= vol_server) & (i <= 40))
that way as soon as the look up table's value exceeds or is equal to the value from Slimserver we pick that volume level and send to the IBM chip. It's not the best solution as there will be about 6 or 7 fishbone volume settings which will sound the same as their neighboring settings.
I agree, it would appear if the fishbone sent a value that didn't appear in the look up table the volume should be set to maximum. Wait a minute, actually I think you found a bug. The while loop will probably increment i to 41 then fail the test and drop out. That would set the vol_mvpmc to a value found 1 byte after the end of the volume_adj table. I would guess the compiler would have reserved memory for the volume_adj followed by the volume_server arrays. That would make the byte after the volume_adj array the first in the volume_server array and that would be zero.
Ok, I still think changing line 640 will solve your problem. I'll see about getting it into the load.
Fishbone is a slimserver webpage skin!! :O)
After looking at the source code, I came to the same opinion regarding the bug. i is incremented as long as it is below 41, so it will be 41 after the last increment and the array pointer is aiming at somewhat afterwards. Since I am just a user of the precompiled dongle.bins and do not have a linux system running for compiling, it would be great if this bug fix could find a quick way into a new precompiled release!! :O)
Thanks for help
I put a fix in the load (20061027). I still don't know exactly what a fishbone skin is skinning so I didn't test it with anything other than a real slimserver. But, the real slimserver works. And I can't see where something that prodeces volume levels that don't match but come close wouldn't work either. If you could, grab the next nightly build, test it and let me know how it works for you.