We can keep talking about the imminent emergence of all-knowing AI, or how best we should train ourselves to serve our future silicon-based overlords. You know a technology is maturing when there is an abundance of jokes about it on the internet. I don't know the use of embedded_init, but 100/101 player_id seems strange.Simple Audio Recognition on a Raspberry Pi using Machine Learning (I2S, TensorFlow Lite) In squeeze-esp32, things are less clear.Ĭustom_player_id = sb_display_init() ? 100 : 101 List is completed on the forum with: ** radio(13) ** touch(14 ) '5' is transporter, '6' is softsqueeze3, '7' is receiver, '8' is squeezeslave, '9' is controller, '10' is boom, '11' is softboom, '12' is squeezeplay Then there are the softplayers: squeezeslave and squeezelite (I can't remember how they are categorised). Yes SLiMP3 is different from SB1/SB1G from SB2/SB3, Transproter, Boom (screen sizes,) and then Receiver no screen, Touch /radio - controls own display control and own menus. The important bit is how are screen supported wrt LMS. It will not be a copycat of a SB, but I think it's fairly complete to have a text displayĭon't overthink. Now, I think there is a project which give external display for squeezelite (I'm not talking about JiveLite of course) but the name is escaping me now. Your call, but it will probably save you a fair bit of time if you want a legacy SB box. It's not just display the bitmap, unless you tell LMS you don't have local scrolling capabilities, in which case it will do it for you (but more jumpy) You can start from scratch, but it's a fair bit of work as the handling of bitmap and background and scrolling is a bit funny.
REUSING RASPBERRY PI CODECS DRIVERS
I even have a independent set of drivers exactly for the type of screens you want to use.
REUSING RASPBERRY PI CODECS CODE
RobinTo add to advice, if you really want the exact LMS screen, you really should look at my code on squeezelite-esp32. (even if it means having less rich information/interaction with the scree). This explains why I didn't find anything related to artists, song, album names in slimproto.įrom what you say, I begin to think that the best way to go is by using an independent program, consuming player info through LMS CLI and registering IR event from LIRCD to adjust brightness. but it makes sense as SB3 were always advertised as very thin, even delegating infrared command handling to the server. I didn't remember that the display was generated server side and sent as raster images to SB players. I suppose, squeezelite declares itself as a "receiver" so it's possible that it won't receive brightness information. It makes sense as my Transporter (hopefully still alive) as more screens to control than my SB3s. I didn't know that the player advertised/declared itself as being of a given type. I'm more comfortable with the raspberry version so I don't think I'll dig too deep in this project, but It can be a nice source of inspiration. Thank you for both the warning for the "no screen device" and for pointing me to squeezeESP32 projects. I think squeezlite is a device type with no screen so LMS will not generate the bit maps (just like Touch)Ĭheck out Philippe SqueezeAMP32/SqueezeESP32 which he put into an SB3 case - as he added a screen onto a squeezelite player.Hi bpa, So I want to retrieve player screen brightness from the server to mimic as much as possible the original SB3 behavior, to be able to use the brightness touch on the remote control, and use it to drive the OLED screen brightness. Maybe by doing something simpler from scratch, just to display "now playing" and alarms (I was using my SB3 as an advanced alarm clock and I miss it terribly!) Maybe by using some existing program like: I'd like to drive a wide OLED display to emulate the original SB3 VFD: I have a headless raspberry plugged to a SMSL AD18 digital AMP. seemingly due to DAC capacitors old age wear) and I'm building a piCorePlayer from spare parts I had lying around. My two squeezebox 3 went dead recently (reboots in loop, mostly when playing audio. If I finally add an handler for grfb commands in squeezelite/master/slimproto.c what would be the best way to interface squeezelite with a third party application? Is there an easy way to do it without patching squeezelite? I'd like to retrieve player brightness value that should be sent by LMS to squeezelite via Slimproto "grfb" command. (cross post from "Linux / Unix" forum as the question is also "developer" oriented)
0 kommentar(er)
