Home of the Squeezebox™ & Transporter® network music players.
Page 1 of 3 123 LastLast
Results 1 to 10 of 27
  1. #1
    Senior Member vrobin's Avatar
    Join Date
    May 2007
    Posts
    477

    retrieve brightness from squeezelite to drive an OLED screen

    (cross post from "Linux / Unix" forum as the question is also "developer" oriented)

    Hi,

    Short question:
    I'd like to retrieve player brightness value that should be sent by LMS to squeezelite via Slimproto "grfb" command.

    Is there an easy way to do it without patching squeezelite?

    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?
    • reusing visualization shared memory
    • using stdout
    • a file
    • something else?


    Long Story:
    My two squeezebox 3 went dead recently (reboots in loop, mostly when playing audio... seemingly due to DAC capacitors old age wear) and I'm building a piCorePlayer from spare parts I had lying around.
    I have a headless raspberry plugged to a SMSL AD18 digital AMP.

    I'd like to drive a wide OLED display to emulate the original SB3 VFD:


    Maybe by using some existing program like:
    https://github.com/shunte88/LMSMonitor

    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!)

    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.

    Any hint welcome!
    Robin

  2. #2
    Senior Member
    Join Date
    Aug 2012
    Location
    Austria
    Posts
    1,201
    Quote Originally Posted by vrobin View Post
    I'd like to retrieve player brightness value that should be sent by LMS to squeezelite via Slimproto "grfb" command.
    Is there an easy way to do it without patching squeezelite?
    Setting the log to warning will cause squeezelite to output unknown slimproto commands to stdout. Another program could react to that.

    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?
    depends on the third party application

    • reusing visualization shared memory
    • using stdout
    but this is usually not a good approach

    • a file
    • something else?
    directly execute a command
    FIFOs (named pipes)
    use IPC (e.g. domain sockets)
    Various SW: Web Interface | TUI | Playlist Editor / Generator | Music Classification | Similar Music | Announce | EventTrigger | DB Optimizer | Chiptunes | LMSlib2go | ...
    Various HowTos: build a self-contained LMS | Bluetooth/ALSA | Control LMS with any device | ...

  3. #3
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,403
    I think squeezlite is a device type with no screen so LMS will not generate the bit maps (just like Touch)

    Check out Philippe SqueezeAMP32/SqueezeESP32 which he put into an SB3 case - as he added a screen onto a squeezelite player.

  4. #4
    Senior Member vrobin's Avatar
    Join Date
    May 2007
    Posts
    477
    Hi Roland,

    Thanks for your answer.

    Quote Originally Posted by Roland0 View Post
    Setting the log to warning will cause squeezelite to output unknown slimproto commands to stdout. Another program could react to that.
    Nice suggestion, it will help to see when grfb commands are sent or not. I don't know if this commands is sent on a regular basis or only on change.
    If the grfb command is sent only on change, I may need some way to ask for last known value for the brightness

    Quote Originally Posted by Roland0 View Post
    > reusing visualization shared memory
    > reusing stdout
    depends on the third party application
    but this is usually not a good approach

    directly execute a command
    FIFOs (named pipes)
    use IPC (e.g. domain sockets)
    I considered those options too... it's been a long time since I last program C/IPC under Linux... I'll check If I can find something simple, non blocking.
    As shared memory is already used by squeezelite, it seems reasonnable to build on a bloc already used in the program.

    First I'll see output from the warning logs... I may have surprised as bpa noted... if squeezelite is recognized as a headless player, the brightness might not even been sent by LMS...

  5. #5
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,065
    Quote Originally Posted by vrobin View Post
    Hi Roland,

    Thanks for your answer.



    Nice suggestion, it will help to see when grfb commands are sent or not. I don't know if this commands is sent on a regular basis or only on change.
    If the grfb command is sent only on change, I may need some way to ask for last known value for the brightness



    I considered those options too... it's been a long time since I last program C/IPC under Linux... I'll check If I can find something simple, non blocking.
    As shared memory is already used by squeezelite, it seems reasonnable to build on a bloc already used in the program.

    First I'll see output from the warning logs... I may have surprised as bpa noted... if squeezelite is recognized as a headless player, the brightness might not even been sent by LMS...
    Squeezelite is headless, no command sent. You have to use another model number, like I did in squeezelite-esp32. Thatĺs an example of a full rebuild of a legacy SB with display, buttons, IR, rotary etc
    LMS 8.2 on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  6. #6
    Senior Member vrobin's Avatar
    Join Date
    May 2007
    Posts
    477
    Quote Originally Posted by bpa View Post
    I think squeezlite is a device type with no screen so LMS will not generate the bit maps (just like Touch)

    Check out Philippe SqueezeAMP32/SqueezeESP32 which he put into an SB3 case - as he added a screen onto a squeezelite player.
    Hi bpa,

    Thank you for both the warning for the "no screen device" and for pointing me to squeezeESP32 projects.
    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.

    I didn't know that the player advertised/declared itself as being of a given type.
    It makes sense as my Transporter (hopefully still alive) as more screens to control than my SB3s.
    I suppose, squeezelite declares itself as a "receiver" so it's possible that it won't receive brightness information.

    I didn't remember that the display was generated server side and sent as raster images to SB players.. but it makes sense as SB3 were always advertised as very thin, even delegating infrared command handling to the server.
    This explains why I didn't find anything related to artists, song, album names in slimproto.

    From 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... (even if it means having less rich information/interaction with the scree).

    Robin

  7. #7
    Senior Member
    Join Date
    Oct 2005
    Location
    Ireland
    Posts
    20,403
    Quote Originally Posted by vrobin View Post
    Thank you for both the warning for the "no screen device" and for pointing me to squeezeESP32 projects.
    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.
    Don't overthink. It is suqeezelite on other hardware. The other hardware is mainly hidden. The important bit is how are screen supported wrt LMS.

    I didn't know that the player advertised/declared itself as being of a given type.
    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. Then there are the softplayers: squeezeslave and squeezelite (I can't remember how they are categorised).

    It makes sense as my Transporter (hopefully still alive) as more screens to control than my SB3s.
    I suppose, squeezelite declares itself as a "receiver" so it's possible that it won't receive brightness information.
    Transporter has two similar screens. I don't think squeezelite is a "receiver" as receiver has less capabilities (e.g. cannot declare its own capabilties such as codecs, https support etc.)

    I didn't remember that the display was generated server side and sent as raster images to SB players.. but it makes sense as SB3 were always advertised as very thin, even delegating infrared command handling to the server.
    This explains why I didn't find anything related to artists, song, album names in slimproto.
    Absolutely everything on screen is done in LMS - all the menus are generated within LMS. SB3/Boom/Transporter are bitmapped displays with some hardware assist for side scrolling (even side scrolling used to be done via s/w)

    From 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... (even if it means having less rich information/interaction with the scree).
    This is why I think you should look at how screen have veen added to Squeezelite withing SqueezeESp32 players.

  8. #8
    Senior Member vrobin's Avatar
    Join Date
    May 2007
    Posts
    477
    Quote Originally Posted by philippe_44 View Post
    Squeezelite is headless, no command sent. You have to use another model number, like I did in squeezelite-esp32. Thatĺs an example of a full rebuild of a legacy SB with display, buttons, IR, rotary etc
    Hi Philippe,

    Thanks for the information... I'll do a little digging in the squeezelite-esp32 repository. I'll look at the model number advertised by squeezelite-esp32.


    Allow me to take advantage of you reading this thread on asking a few questions on squeezelite-eps32 (maybe I'll find answer by myself in the project doc):
    * Can I built a squeezelite-esp32 with only an esp32 board and some off the shelf breadboard, without having to build an electronic card from scratch?
    (I need SPDIF output to connect to digital amplifier, IR receiver on a GPIO for remote control and OLED screen SPI)
    * Is the esp32 powerful/stable enough for standard audio play? (no need for DSD512 ).

  9. #9
    Senior Member
    Join Date
    May 2008
    Location
    Canada
    Posts
    7,065
    Quote Originally Posted by vrobin View Post
    Hi bpa,

    Thank you for both the warning for the "no screen device" and for pointing me to squeezeESP32 projects.
    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.

    I didn't know that the player advertised/declared itself as being of a given type.
    It makes sense as my Transporter (hopefully still alive) as more screens to control than my SB3s.
    I suppose, squeezelite declares itself as a "receiver" so it's possible that it won't receive brightness information.

    I didn't remember that the display was generated server side and sent as raster images to SB players.. but it makes sense as SB3 were always advertised as very thin, even delegating infrared command handling to the server.
    This explains why I didn't find anything related to artists, song, album names in slimproto.

    From 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... (even if it means having less rich information/interaction with the scree).

    Robin
    To add to @bpa advice, if you really want the exact LMS screen, you really should look at my code on squeezelite-esp32. I even have a independent set of drivers exactly for the type of screens you want to use. 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. 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)

    Your call, but it will probably save you a fair bit of time if you want a legacy SB box. 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. It will not be a copycat of a SB, but I think it's fairly complete to have a text display
    LMS 8.2 on Odroid-C4 - SqueezeAMP!, 5xRadio, 5xBoom, 2xDuet, 1xTouch, 1xSB3. Sonos PLAY:3, PLAY:5, Marantz NR1603, Foobar2000, ShairPortW, 2xChromecast Audio, Chromecast v1 and v2, Squeezelite on Pi, Yamaha WX-010, AppleTV 4, Airport Express, GGMM E5, RivaArena 1 & 3

  10. #10
    Senior Member vrobin's Avatar
    Join Date
    May 2007
    Posts
    477
    Quote Originally Posted by bpa View Post
    Don't overthink. It is suqeezelite on other hardware. The other hardware is mainly hidden. The important bit is how are screen supported wrt LMS.

    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. Then there are the softplayers: squeezeslave and squeezelite (I can't remember how they are categorised).
    https://wiki.slimdevices.com/index.p..._protocol.html has the list:

    The Device ID of the player.
    '2' is squeezebox. '3' is softsqueeze, '4' is squeezebox2,. '5' is transporter, '6' is softsqueeze3, '7' is receiver, '8' is squeezeslave, '9' is controller, '10' is boom, '11' is softboom, '12' is squeezeplay
    List is completed on the forum with: ** radio(13) ** touch(14 )

    Squeezelite says helo as a squeezeplay:
    pkt.deviceid = 12; // squeezeplay

    In squeeze-esp32, things are less clear...

    u8_t custom_player_id = 12;

    void embedded_init(void) {
    mutex_create(slimp_mutex);
    sb_controls_init();
    custom_player_id = sb_display_init() ? 100 : 101;
    }

    I don't know the use of embedded_init, but 100/101 player_id seems strange.


    Quote Originally Posted by bpa View Post

    This is why I think you should look at how screen have veen added to Squeezelite withing SqueezeESp32 players.
    I'm on it
    I also kind like the result of : https://github.com/shunte88/LMSMonitor

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •