Home of the Squeezebox™ & Transporter® network music players.
Page 2 of 7 FirstFirst 1234 ... LastLast
Results 11 to 20 of 63
  1. #11
    Senior Member Michaelwagner's Avatar
    Join Date
    Apr 2005
    Location
    Oakville, Ontario, Canada
    Posts
    2,024
    The sound hardware in most laptops is abysmal. I wanted the slim (and before that the audiotron) to produce high quality sound. If I just wanted an MP3 player to play out the lousy sound hardware of the laptop, there are a number of solutions to that problem.

  2. #12
    Senior Member Michaelwagner's Avatar
    Join Date
    Apr 2005
    Location
    Oakville, Ontario, Canada
    Posts
    2,024
    oh, but thank you for the suggestion of foobar2000. It might be a good alternative for monitoring (the DJ often wants to listen to a song before playing it, to see if it fits the current mood, and laptop hardware is up to that task).

    Michael

  3. #13
    Senior Member JJZolx's Avatar
    Join Date
    Apr 2005
    Location
    Colorado
    Posts
    11,531
    Quote Originally Posted by Michaelwagner
    The sound hardware in most laptops is abysmal. I wanted the slim (and before that the audiotron) to produce high quality sound. If I just wanted an MP3 player to play out the lousy sound hardware of the laptop, there are a number of solutions to that problem.
    That's why I suggested an external soundcard - I figured you were using a laptop. It would eliminate the Squeezebox and divorce you from being stuck using SlimServer. If the laptop had S/PDIF out then you might also go from the laptop to an external DAC of your choice. In all three hardware scenarios you have a single external piece of gear, but only the setup with the SqueezeBox limits you to working with the SlimServer software and its mega-footprint.
    ________
    video reviews
    Last edited by JJZolx; 2011-01-22 at 16:42.

  4. #14
    Senior Member Michaelwagner's Avatar
    Join Date
    Apr 2005
    Location
    Oakville, Ontario, Canada
    Posts
    2,024
    JJZolx:

    I appreciate your comments and will check them out in due time.

    In the mean time, I already own 2 squeezeboxes (squeezeboxen?) and don't have a lot of money to buy more things. I'd rather find a way to use the hardware I already have (provided that's possible and practical).

    The point of posting on this forum was to find a squeezebox solution, not another one. I'm not the first one to find the squeezebox "resource footprint" large.

    Back to the original questions: any more answers?

    1. Why is (MP3) tag scanning so resource intensive?

    2. I thought the switch to a database system in 6 was supposed to address this problem.

    3. Given that it is so resource intensive (and for every improvement in code efficiency, someone out there will have a larger library of songs ... ) how about these solutions:

    4. Can the scanning and database service be turned off in the current code (something like flush cache, scan never)? Does anything I care about (song information like title and duration) break?

    5. Can the user interface be separated from the "hardware feeding"
    a. in the current code?
    b. as a future enhancement?

    I partially answered one of my own questions - I found that if you start a rescan and then shut down the server, it clears the cache and doesn't restart the scan when you restart the server. After that, if you request songs via the web interface, it scans only those songs you request (to get the title, artist, etc, info, I guess). That gives me hope that commenting out the global scan in code (once I download active state perl) will yield at least a crude solution for my specific case.

    Michael

  5. #15
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,352

    Re: Slimserver footprint, time and space,and an architectural suggestion

    Just to give at least one answer :-)

    > 1. Why is (MP3) tag scanning so resource intensive?


    Don't know.

    > 2. I thought the switch to a database system in 6 was supposed to
    > address this problem.


    Nope. It's not intended to address resource intensive scanning directly.
    The database should offer a more stable mechanism to manage the
    information found during the scan. And it should considerably lower memory
    consumption with large collections. In slimserver <6 everything was kept
    in memory. Now it's written to a database.

    > 4. Can the scanning and database service be turned off in the current
    > code (something like flush cache, scan never)? Does anything I care
    > about (song information like title and duration) break?


    No scan, no music information. But normally you scan your collection once
    in a while. It should not have an impact in everyday usage.

    > I partially answered one of my own questions - I found that if you
    > start a rescan and then shut down the server, it clears the cache and
    > doesn't restart the scan when you restart the server. After that, if
    > you request songs via the web interface, it scans only those songs you
    > request (to get the title, artist, etc, info, I guess). That gives me
    > hope that commenting out the global scan in code (once I download
    > active state perl) will yield at least a crude solution for my specific
    > case.


    Do whatever you want :-). But I really don't get what you want. What do
    you need slimserver for if you want neither user interface nor the
    information?!?

    --

    Michael

    -----------------------------------------------------------
    Help translate SlimServer by using the
    StringEditor Plugin (http://www.herger.net/slim/)


  6. #16
    Senior Member Michaelwagner's Avatar
    Join Date
    Apr 2005
    Location
    Oakville, Ontario, Canada
    Posts
    2,024
    Quote Originally Posted by mherger
    Just to give at least one answer :-)
    I appreciate the effort.

    > 2. I thought the switch to a database system in 6 was supposed to address this problem.


    Nope. It's not intended to address resource intensive scanning directly. The database should offer a more stable mechanism to manage the information found during the scan. And it should considerably lower memory consumption with large collections. In slimserver <6 everything was kept in memory. Now it's written to a database.
    OK, I must admit, I didn't spend enough time benchmarking 6. Maybe the memory footprint is smaller when re-starting after a full scan.

    No scan, no music information. But normally you scan your collection once in a while. It should not have an impact in everyday usage.
    First part: slim will scan songs that are queued for playback to get the song information even if they aren't in the database.
    Second part: For household use, yes. For DJ use, not necessarily true. One might bring different collections to a gig and have to switch them. Or have a hardware failure and have to switch to a backup system.

    I really don't get what you want. What do you need slimserver for if you want neither user interface nor the information?!?
    To drive the hardware (economically). The thing everyone who looks at the pubs thinks the software does.

    I think it's quite clear there are 2 different purposes being served by the slimserver software - drive the hardware and support the information database. These are fundamentally different things, have different "punctuality" requirements, etc.

    Driving the hardware is a real-time operation. The info database, no one cares if it's 200ms late.

    It seems to me they should be separate processes (in the operating system sense). The fact that I don't happen to need one of them is the back door whereby I came to this conclusion, but I think the architecture is sound regardless.

    Michael

  7. #17
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,352

    Re: Slimserver footprint, time and space,and an architectural suggestion

    >> No scan, no music information. But normally you scan your collection
    >> once in a while. It should not have an impact in everyday usage.

    > First part: slim will scan songs that are queued for playback to get
    > the song information even if they aren't in the database.


    ....or _only_ if they aren't in the database? I don't know how you tested
    this. But could your repeat the test after a complete scan?

    > Second part: For household use, yes. For DJ use, not necessarily true.
    > One might bring different collections to a gig and have to switch them.
    > Or have a hardware failure and have to switch to a backup system.


    Hardware failure might be an exception :-).

    >> I really don't get what you want. What do you need slimserver for if you
    >> want neither user interface nor the information?!?

    > To drive the hardware (economically). The thing everyone who looks at
    > the pubs thinks the software does.


    ....and you're feeding the playlist, the songs etc. all yourself by the
    means of your own application?

    > I think it's quite clear there are 2 different purposes being served by
    > the slimserver software - drive the hardware and support the information
    > database. These are fundamentally different things, have different
    > "punctuality" requirements, etc.


    But you'll have to admit that there won't be many users who use a SB as a
    luxury soundcard. I've never heard of anyone else using slimserver as a
    hardware driver _only_ before...

    Honestly: in my eyes your application is too esoteric, to expect
    developpers putting much effort in supporting it (but this is only my
    opinion). I assume the current architecture - while it's technically not
    the most sophisticated - will satisfy close to 1100% of the users. It just
    works for most of us.

    What's your main concern: latency or memory foodprint? I was able to
    reduce memory usage of a stock 6.0 trunk copy from about 43MB to 36MB
    within an hour (remove plugins, setup, XML::Simple). Next victim would
    have been the web interface. But I'm not sure if this is worth the effort.

    Have you ever thought of writing your own application to use slimproto and
    feed the device directly?

    --

    Michael

    -----------------------------------------------------------
    Help translate SlimServer by using the
    StringEditor Plugin (http://www.herger.net/slim/)


  8. #18
    Babelfish's Best Boy mherger's Avatar
    Join Date
    Apr 2005
    Location
    Switzerland
    Posts
    20,352

    Re: Slimserver footprint, time and space,and an architectural suggestion

    >> It just works for most of us.
    >
    > That sentence can be read in at least two ways; I'm sure you meant "It
    > just *works* ..." but to my mind, "It *just* works". I've noticed


    You're right, of course, it *works* :-)

    >> Have you ever thought of writing your own application to use slimproto
    >> and feed the device directly?

    >
    > I have, several times, but each time I get anywhere near the slimserver
    > code I think of something more important I have to do...


    So might do Dean, Dan & co. when reading about splitting the code ;-).

    --

    Michael

    -----------------------------------------------------------
    Help translate SlimServer by using the
    StringEditor Plugin (http://www.herger.net/slim/)


  9. #19
    Robin Bowes
    Guest

    Slimserver footprint, time and space,and an architectural suggestion

    Michael Herger wrote:
    > But you'll have to admit that there won't be many users who use a SB as
    > a luxury soundcard. I've never heard of anyone else using slimserver as
    > a hardware driver _only_ before...


    Ah, but that's because you can't. This is essentially the purpose of
    Microsoft's Media Centre Connect - it allows music from PCs to be
    streamed to compatible hardware devices.

    Personally, I'd love to be able to do that. Whilst I find slimserver
    adequate for managing what I play on my SB, I'd much prefer to have the
    freedom to use other software to do this and to stream the audio to a
    "slimmed" down slimserver process that just deals with the audio (and
    IR, and display updating).

    > It just works for most of us.


    That sentence can be read in at least two ways; I'm sure you meant "It
    just *works* ..." but to my mind, "It *just* works". I've noticed
    occasional dropouts playing back flac over a wired connection. I'm sure
    this wouldn't happen if the streaming process was separated from the
    playlist management.

    > Have you ever thought of writing your own application to use slimproto
    > and feed the device directly?


    I have, several times, but each time I get anywhere near the slimserver
    code I think of something more important I have to do...

    R.

    --
    http://robinbowes.com


  10. #20
    Robin Bowes
    Guest

    Slimserver footprint, time and space,and an architectural suggestion

    Michael Herger wrote:

    >> I have, several times, but each time I get anywhere near the
    >> slimserver code I think of something more important I have to do...

    >
    >
    > So might do Dean, Dan & co. when reading about splitting the code ;-).


    It's not that big a job, *if* you understand the existing code. All the
    code's there, it just needs architecting at a high level and
    re-organising. I'm sure Dean/Dan/Vidur/ et al. are more than up to the task.

    R.

    --
    http://robinbowes.com


Posting Permissions

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