Home of the Squeezebox™ & Transporter® network music players.
Page 10 of 12 FirstFirst ... 89101112 LastLast
Results 91 to 100 of 120
  1. #91
    Senior Member
    Join Date
    Dec 2020
    Posts
    131
    Maybe...

    As it happens I do already have a crossdev environment for armv5te, but it will be a major challenge to create a binary that will run with the existing libc on the Radio.

  2. #92
    Senior Member ralphy's Avatar
    Join Date
    Jan 2006
    Location
    Canada
    Posts
    2,856
    Quote Originally Posted by gordonb3 View Post
    Maybe...

    As it happens I do already have a crossdev environment for armv5te, but it will be a major challenge to create a binary that will run with the existing libc on the Radio.
    I can quickly build a jive binary for the radio with the changes to jive_jiffies from post #89, but it will based on the current community firmware not the stock.
    Ralphy

    1-Touch, 5-Classics, 3-Booms, 2-UE Radio
    Squeezebox client builds donations always appreciated.

  3. #93
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    802
    Quote Originally Posted by Steevee28 View Post
    Ok guys, I heavily edited my post #79, trying to concentrate all our findings so far, because, as my own previous posts showed, I already forgot about many things that were discussed and identified as problems or possible solutions before.

    So it seems to urgently need a place summing up all these findings.
    I hope that you agree to what I've written there. Please tell me if you don't.
    As regards "extending the upper bits", I do recall that that potentially raises some very hairy issues within LUA, at least the version of LUA that the Radio runs. These stem from its automatic promotion of integers to floats in the LUA 'number' type. I am hazy on the detail, and perhaps it is easily managed.

    I also recall a degree of inconsistency (bugs) between the definition of the underlying data types on 32 and 64 bit platforms. It might all be better in a later version of LUA. And I'm hazy on that subject too, it's a while since I looked. But has implications if one is looking beyond just the Radio/Touch/Controller.

  4. #94
    Senior Member Steevee28's Avatar
    Join Date
    Feb 2010
    Location
    Mannheim, Germany
    Posts
    103
    Quote Originally Posted by Steevee28 View Post
    Are you able to edit the jive_jiffies() function in src/common.h to return a timer value right from the start that is - let's say - 1 minute before wrapping (corresponding to 0x7FFF15A0) ? (...)
    @gordonb3: Oh, take care, one minute may be too short to be able to recover from a test firmware build that resets itself because of a watchdog reset once each minute. maybe 10 or 15 minutes or so is be better...
    1x Squeezebox Classic, 3x Radio, 1x Touch, LMS 7.9.1 running on ODROID-U3, Ubuntu 16.04 and I'm happy with it! :)

  5. #95
    Senior Member
    Join Date
    Dec 2020
    Posts
    131
    Oh Christ...

    I'm going about this all the way wrong. I was focussing on matching the numbers inside the LUA scripts, patching the code to be indifferent to the sign change, but the whole point of this jive_jiffies() thing is for all independent components to have their time values synchronized. And so even if I can get the LUA part to continue running with negative values for time this is bound to result in the unwanted behaviour that led to the introduction of jive_jiffies() in the first place.

    So let's break this down. As I see it there are two separate issues that require addressing:

    1. sign change
      There is a difficult way and a simple way to address this. The problem with the simple way is that this requires the jive executable to be recompiled and therefore this is not a simple patch. The difficult and user patchable way is to handle the sign change inside the LUA scripts and the most straight forward method in this case will likely be to change all references to `getTicks()` to a new function `getCorrectedTicks()` that adds 4,294,967,296 when `getTicks()` returns a negative number.
    2. max integer value overrun
      Be noted that it will be rather pointless to even start addressing this issue without having considered #1 first. As has been stipulated earlier the LUA number format is different from what `jive_jiffies()` returns. More specifically, `lua_number` has a much higher maximum value than the `uint32_t`that is used internally inside the jive executable AND the ALSA backend. At this point I'm unsure what would be the best or even simplest way to address this as both methods imply a fairly big change to the code base. Implementing some MAX_VAL routine inside the LUA scripts to handle loop issues is one method, the other one would involve changing the value type to be compatible all over the board (i.e. a double) which appears to have the highest chance of not running into other issues, be it somewhat dubious to store an integer value in a floating point type.

  6. #96
    Senior Member Steevee28's Avatar
    Join Date
    Feb 2010
    Location
    Mannheim, Germany
    Posts
    103
    Quote Originally Posted by gordonb3 View Post
    1. sign change
    This has been discussed before and there is an easy solution. As @mrw pointed out, it's called modular arithmetic, which is default in C.
    Please don't be angry with me, but for me, it seems that you still don't really understand why `if (a < b)` is not the same as `if ( (a-b) < 0 )` in C language, although being "mathematically" identical and why it is thus crucial to only work with value differences instead of directly comparing timer values.
    See e.g. here https://image.slideserve.com/347022/...mplement-l.jpg for an explanation. The value range of signed integer numbers in C is circular. That's the whole trick and that makes it all easy.

    --------------------
    EDIT: Reading your post again, I think that I got completely wrong what you wrote, so please forget what I've written here. I'm sure that you know very well how modular arithmetic is working, so please accept my apologies.
    --------------------

    It's absolutely correct what you wrote, but as @ralphy pointed out, he is able to rebuild the Jive executable, or did I get this wrong? There is a community build of Radio firmware and @ralphy is even building PiCorePlayer from scratch, as far I know. So we can change that bit of code and thus fixing the C-part should be pretty simple.

    Quote Originally Posted by gordonb3 View Post
    2. max integer value overrun
    Yes, the Lua part is much harder to fix, because, as you wrote, Lua's number type has a completely different value range than the jiffy_timer.
    @mrw already proposed a good solution that seems to be the cleanest way: encapsulate the original datatype of the jiffy timer (int32_t) in a Lua userdata type and simply use the same modular arithmetic inside it's C implementation.
    I think that this might be exacly what you had in mind by writing "changing the value type to be compatible all over the board".

    Of course, it is a little bit of work to build that userdata type, but fixing the Lua code should then be easily done in less than an hour, snce it seems to only be 2 Lua source files (Framework.lua and Timer.lua) in total that need to be looked through.
    Last edited by Steevee28; 2021-03-12 at 15:48. Reason: added apologies. sorry!!! and fixed syntax errors
    1x Squeezebox Classic, 3x Radio, 1x Touch, LMS 7.9.1 running on ODROID-U3, Ubuntu 16.04 and I'm happy with it! :)

  7. #97
    Senior Member
    Join Date
    Dec 2020
    Posts
    131
    Quote Originally Posted by Steevee28 View Post
    It's absolutely correct what you wrote, but as @ralphy pointed out, he is able to rebuild the Jive executable, or did I get this wrong? There is a community build of Radio firmware and @ralphy is even building PiCorePlayer from scratch, as far I know. So we can change that bit of code and thus fixing the C-part should be pretty simple.
    As I read it this he can only make that change based on the community version, which to me appears to imply that he uses a newer development platform that creates incompatible binaries. I'm not yet willing to go that way so I'm currently investigating a different route. As my armv5te development machine originally came with a Debian Squeeze based OS, which seems to be what the Squeezeboxes are based on as well, I did some digging and found the original install image. I'll need to change some parameters as Squeeze is obviously archived now and I will need build-essentials to get me going, but I should then be able to compile the squeezeplay sources to create a jive binary that is compatible with my Radio.

    In the meantime I have submitted a pull request to Ralph's fork to be included in the community build. The change is of course currently untested on the actual platform but I'm certain it will solve the sign change in the LUA part of squeezeplay.

  8. #98
    Senior Member Steevee28's Avatar
    Join Date
    Feb 2010
    Location
    Mannheim, Germany
    Posts
    103
    Quote Originally Posted by mrw View Post
    (...) perhaps a LUA user defined type might be made to look and act cleaner. (...)
    Question: @mrw do you think that a userdata type in Lua can be implemented along with a metatable properly overloading all required operators in such a way, that no code changes at all would be required on Lua side???

    I'm having Lua plugin scripts in mind here which might also use timer values. I forgot about them until now.
    1x Squeezebox Classic, 3x Radio, 1x Touch, LMS 7.9.1 running on ODROID-U3, Ubuntu 16.04 and I'm happy with it! :)

  9. #99
    Senior Member
    Join Date
    May 2010
    Location
    London, UK
    Posts
    802
    Quote Originally Posted by Steevee28 View Post
    Question: @mrw do you think that a userdata type in Lua can be implemented along with a metatable properly overloading all required operators in such a way, that no code changes at all would be required on Lua side???
    That was my first thought. I think it probably is possible, but the devil will be in the detail, and requires proper study. One would define a 'fallback' operation, I believe.

    One detail is that the overhead of doing it would be increased relative to simple number comparisons[1]. Would this adversely impact performance on Radio/Touch/Controller ? I simply do not know. Perhaps not, but there must be overhead incurred in despatching the 'fallback'.

    [1] And they will be integer comparisons, by virtue of the lua "integer patch".

  10. #100
    Senior Member
    Join Date
    Dec 2020
    Posts
    131
    I'm just wondering. Did you guys read this commit message from the git history?

    Change from SDL_GetTicks() to jive_jiffies(). This allows a single time epoch to be
    shared between the main and alsa backend processes.

    Bug #12909
    I have no working link to the original bug tracker, but from this it seems vital for the various components to be using the same time reference and at present the time registration in that ALSA backend will reset to zero after 49 days 17 hours (-ish), which is therefore what the LUA frontend should do as well and we currently have no clue what will happen if we don't because we have never been able to get past the 24th day.

Posting Permissions

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