rpress;636893 Wrote: > I'm having difficulty implementing the rotary encoder volume knob. The > IR command interface does not lend itself well to this, the increments > are too small. I tried to repeat the IR command but it seems there is > repeat code on the server side that is thwarting me. Any idea how I > could change the volume but with a larger step than the IR command will > give me?
Are you modifying the IR code loop in interactive.c? The IR repeat should be taken care of as you can press and hold the space bar in interactive mode to STOP playing, which is all handled by the server. Are you "stuffing" volup/voldown codes in that loop? If so, it should work as I can press and hold either the plus or minus key to change the volume rapidly. case '-': ir = 0x768900ff; break; /* voldown */ case '+': ir = 0x7689807f; break; /* volup */ Perhaps you could send more than one ir code for each change. Another option I can think of is you could open a connection to the cli, and send 'mixer volume ' change commands with whatever increment/decrement you'd like, through that socket connection using your player MAC address as the target. rpress;636893 Wrote: > I removed the mutex locks from pa_callback by moving some stuff around. > Maybe I did it wrong, but it didn't seem much better. Interesting. Everything I researched pointed to the locks in the callback being the root cause but you do need to change the buffering as well. Regardless, the locks should not be in the callback. Do you still have those changes? It would be great to incorporate them into trunk. rpress;636893 Wrote: > When stuttering I see "pa_callback: SLIMAUDIO_BUFFER_STREAM_UNDERRUN". > It seems like this happens at two different times. Sometimes it > happens as the old track is still going before it switches to the new > one. I would guess in this case the thread that stuffs the data into > the decoder does not have enough priority or something, as it should > have plenty of buffer available. Switching to the new track is taking > too much CPU away from it. Just guessing at this point. That would be in slimaudio_http.c. The UNDERRUN error indicates that the output buffer is empty, so you could be correct with that assumption. rpress;636893 Wrote: > However, usually I only see the underrun when the new track is starting > up. I've modified the predelay into a prebuffer where it will wait for > X ms of buffer to be filled before starting the track. This means that > it won't always wait for X ms of time if the buffer fills up quick. > Also it means it will wait longer if it takes longer. Not a perfect > solution but it seems to work better for me. How would that affect player sync? -- ralphy Ralphy *4*-Classics, *2*-Booms, *12*-Squeezeslaves 'Squeezeslave' (http://code.google.com/p/squeezeslave/) 'donations' (https://www.paypal.com/cgi-bin/webscr?cmd=_donations&business=LL5P6365KQEXN&lc=CA&item_name=Squeezeslave¤cy_code=USD&bn=PP%2dDonationsBF%3abtn_donate_SM%2egif%3aNonHosted) always appreciated. ------------------------------------------------------------------------ ralphy's Profile: http://forums.slimdevices.com/member.php?userid=3484 View this thread: http://forums.slimdevices.com/showthread.php?t=83362 _______________________________________________ discuss mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/discuss
