[livesupport-dev] latest results
  • This is a multipart message in MIME format.
    --=_alternative 007290A4C125706B_=
    Content-Type: text/plain; charset="us-ascii"

    Hi,

    My latest results with the newest LS build result in the following delays.

    Files used are
    Songs from Bebel Gilberto's "Tanto Tempo" : 160kbps ogg, 44.1khz
    ads: 128kbps mp3, 22050hz
    DJ Earworm's "Lick the Robot": 256kbps mp3, 44.1khz
    Bob Marley's "Legend": 64kbps mp3, 44.1 khz

    Playing a playlist made up of 2 files from Bebel Gilberto (duration:
    7:18): 4 seconds delay
    Playing a playlist made up of 3 ads (duration: 3:04): 10 seconds delay
    Playing a playlist made up of a combination of music + ads (duration:
    13:19): 14 seconds delay
    Playing a playlist made up of 5 files from Bebel Gilberto (duration
    13:15): 5 seconds delay
    Playing a playlist made up of 12 files from Bob Marley (duration 50:27):
    13 seconds delay

    Granted, some of the files (the ads files are at 22050 and the Marley
    files are at 64kbps, so I don't know if they count) I'm using are not to
    the current standards, so I suppose we can rule their results out for the
    time being.

    Regardless, for the files that are in range (44.1 khz is the only current
    requirement, as I understand it), the delays are improved, but still too
    long.

    Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere in
    your collection. I'd suggest using these in addition to your smil test
    files to get us better triangulation.


    doug

    --=_alternative 007290A4C125706B_=
    Content-Type: text/html; charset="us-ascii"



    Hi,



    My latest results with the newest LS build result in the following delays.



    Files used are

    Songs from Bebel Gilberto's "Tanto Tempo" : 160kbps ogg, 44.1khz

    ads: 128kbps mp3, 22050hz

    DJ Earworm's "Lick the Robot": 256kbps mp3, 44.1khz

    Bob Marley's "Legend": 64kbps mp3, 44.1 khz



    Playing a playlist made up of 2 files from Bebel Gilberto (duration: 7:18): 4 seconds delay

    Playing a playlist made up of 3 ads (duration: 3:04): 10 seconds delay

    Playing a playlist made up of a combination of music + ads (duration: 13:19): 14 seconds delay

    Playing a playlist made up of 5 files from Bebel Gilberto (duration 13:15): 5 seconds delay

    Playing a playlist made up of 12 files from Bob Marley (duration 50:27): 13 seconds delay



    Granted, some of the files (the ads files are at 22050 and the Marley files are at 64kbps, so I don't know if they count) I'm using are not to the current standards, so I suppose we can rule their results out for the time being.



    Regardless, for the files that are in range (44.1 khz is the only current requirement, as I understand it), the delays are improved, but still too long.



    Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere in your collection. I'd suggest using these in addition to your smil test files to get us better triangulation.





    doug


    --=_alternative 007290A4C125706B_=--

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • 11 Comments sorted by
  • > Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere in
    > your collection. I'd suggest using these in addition to your smil test
    > files to get us better triangulation.

    still, could you send me a detailed description of the playlists you use?
    like how long music files, what offsets are used (are they simply
    sequential playlists?), etc...

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • > Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere in
    > your collection. I'd suggest using these in addition to your smil test
    > files to get us better triangulation.

    still, could you send me a detailed description of the playlists you use?
    like how long music files, what offsets are used (are they simply
    sequential playlists?), etc...

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • This is a multipart message in MIME format.
    --=_alternative 000BC0A8C125706C_=
    Content-Type: text/plain; charset="us-ascii"

    The playlists are all simple sequential playlists with default offsets.
    Here is the breakdown:

    Ads 3 files, total duration: 03:04 -- 10 second delay
    =====

    1. Schlitz Beer 1:01 MP3, 24kb/s, Samplerate: 22050Khz
    2. Palm Springs 1:04, MP3, 24kb/s, Samplerate: 22050 Khz
    3. Toyota 1:00, MP3, 24Kb/s, Samplerate: 22050 Khz


    Music 3 files, total duration 10:08 -- 5 second delay
    =======
    1. Lick the Robot, 4:11 MP3, 256Kbps, Samplerate: 44.1 khz
    2. Lonely, 02:25 Ogg, 160kbps, Samplerate: 44.1 khz
    3. So Nice (Summer Samba), 03:33 Ogg, 160 kbps, Samplerate: 44.1 khz

    Bob Marley - Legend,12 files, total duration 50:27 -- 13 second delay
    =======
    1. No woman no cry, 7:07 MP3, 64Kbps, Samplerate: 44.1 khz
    2. Get up stand up, 3:17 MP3, 64kbps, Samplerate: 44.1 khz
    3. Satisfy my soul, 4:32 MP3, 64kbps, Samplerate: 44.1 khz
    4. Jamming, 3:31 MP3, 64kbps, Samplerate: 44.1 khz
    5. Three Little Birds, 3:00 MP3, 64kbps, Samplerate: 44.1 khz
    6. Is This Love, 3:52 MP3, 64kbps, Samplerate: 44.1 khz
    7: One Love/People Get Ready, 2:52 MP3, 64kbps, Samplerate: 44.1 khz
    8. Redemption Song, 3:40 MP3, 64kbps, Samplerate: 44.1 khz
    9: I Shot the Sheriff, 4:41 MP3, 64kbps, Samplerate: 44.1 khz
    10. Stir It Up, 5:34 MP3, 64kbps, Samplerate: 44.1 khz
    11. Could You Be Loved, 3:55 MP3, 64kbps, Samplerate: 44.1 khz
    12. Buffalo Soldier, 4:17 MP3, 64kbps, Samplerate: 44.1 khz

    Music + Ads, 3 files + 1 playlist, total duration 13:19 -- 14 second delay
    =======
    1. Lonely, 02:25 Ogg, 160 kbps, Samplerate: 44.1 khz
    2. Ads (playlist, see above), duration: 3:05
    3. So Nice (Summer Samba), 3:33 Ogg, 160 kbps, Samplerate: 44.1 khz
    4. Mais Feliz, 4:17 Ogg, 160 kbps, Samplerate: 44.1 khz









    darkeye@tyrell.hu
    08/28/05 10:57 PM
    Please respond to livesupport-dev


    To: livesupport-dev@campware.org
    cc:
    Subject: Re: [livesupport-dev] latest results


    > Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere
    in
    > your collection. I'd suggest using these in addition to your smil test
    > files to get us better triangulation.

    still, could you send me a detailed description of the playlists you use?
    like how long music files, what offsets are used (are they simply
    sequential playlists?), etc...



    --=_alternative 000BC0A8C125706C_=
    Content-Type: text/html; charset="us-ascii"



    The playlists are all simple sequential playlists with default offsets. Here is the breakdown:



    Ads 3 files, total duration: 03:04 -- 10 second delay

    =====



    1. Schlitz Beer 1:01 MP3, 24kb/s, Samplerate: 22050Khz

    2. Palm Springs 1:04, MP3, 24kb/s, Samplerate: 22050 Khz

    3. Toyota 1:00, MP3, 24Kb/s, Samplerate: 22050 Khz





    Music 3 files, total duration 10:08 -- 5 second delay

    =======

    1. Lick the Robot, 4:11 MP3, 256Kbps, Samplerate: 44.1 khz

    2. Lonely, 02:25 Ogg, 160kbps, Samplerate: 44.1 khz

    3. So Nice (Summer Samba), 03:33 Ogg, 160 kbps, Samplerate: 44.1 khz



    Bob Marley - Legend,12 files, total duration 50:27 -- 13 second delay

    =======

    1. No woman no cry, 7:07 MP3, 64Kbps, Samplerate: 44.1 khz

    2. Get up stand up, 3:17 MP3, 64kbps, Samplerate: 44.1 khz

    3. Satisfy my soul, 4:32 MP3, 64kbps, Samplerate: 44.1 khz

    4. Jamming, 3:31 MP3, 64kbps, Samplerate: 44.1 khz

    5. Three Little Birds, 3:00 MP3, 64kbps, Samplerate: 44.1 khz

    6. Is This Love, 3:52 MP3, 64kbps, Samplerate: 44.1 khz

    7: One Love/People Get Ready, 2:52 MP3, 64kbps, Samplerate: 44.1 khz

    8. Redemption Song, 3:40 MP3, 64kbps, Samplerate: 44.1 khz

    9: I Shot the Sheriff, 4:41 MP3, 64kbps, Samplerate: 44.1 khz

    10. Stir It Up, 5:34 MP3, 64kbps, Samplerate: 44.1 khz

    11. Could You Be Loved, 3:55 MP3, 64kbps, Samplerate: 44.1 khz

    12. Buffalo Soldier, 4:17 MP3, 64kbps, Samplerate: 44.1 khz



    Music + Ads, 3 files + 1 playlist, total duration 13:19 -- 14 second delay

    =======

    1. Lonely, 02:25 Ogg, 160 kbps, Samplerate: 44.1 khz

    2. Ads (playlist, see above), duration: 3:05

    3. So Nice (Summer Samba), 3:33 Ogg, 160 kbps, Samplerate: 44.1 khz

    4. Mais Feliz, 4:17 Ogg, 160 kbps, Samplerate: 44.1 khz



















    darkeye@tyrell.hu

    08/28/05 10:57 PM

    Please respond to livesupport-dev


           

            To:        livesupport-dev@campware.org

            cc:        

            Subject:        Re: [livesupport-dev] latest results






    > Akos, I'm pretty sure you have some 'real world' mp3s or oggs somewhere in

    > your collection. I'd suggest using these in addition to your smil test

    > files to get us better triangulation.



    still, could you send me a detailed description of the playlists you use?

    like how long music files, what offsets are used (are they simply

    sequential playlists?), etc...






    --=_alternative 000BC0A8C125706C_=--

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Douglas.Arellanes@mdlf.org wrote:
    >
    > The playlists are all simple sequential playlists with default offsets.
    > Here is the breakdown:

    I did some experiments on my own. I made a playlist with four J.S. Bach
    files, totallying about 34 minutes. the opening time for this playlist
    is 0.7 seconds on my machine (1.8 GHz centrino)

    but, how are you opening the files?

    I tested trying to play them from the GUI scratchpad, and it indeed
    takes longer. but the time is not spent moslty on opening. the
    following calls are made then the play button is pressed in the scratchpad:


    cueItemPlayingNow = storage->acquirePlaylist(sessionId,
    playable->getId());
    cuePlayer->open(*cueItemPlayingNow->getUri());
    cuePlayer->start();


    the times for the above are:


    acquire duration: 00:00:01.389374
    open duration: 00:00:00.831224
    start duration: 00:00:00.044801


    so, most of the time spent is for acquiring the playlist from the
    storage. maybe we should open the files as soon as they appear in the
    scratchpad?


    how did you test these files? where / how did you play them?

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • This is a multipart message in MIME format.
    --=_alternative 0045766BC125706C_=
    Content-Type: text/plain; charset="iso-8859-1"
    Content-Transfer-Encoding: quoted-printable

    I'm on a 1.1 Ghz PIII, and am opening the playlists by first putting an=20
    file in LS Studio Live Mode, then hitting the 'stop' button, which should=20
    stop the current file playing and load the playlist in for playing. That's =

    taking me 7-8 seconds after hitting the 'stop' button.

    Does waiting for a playlist item to end officially make any difference in=20
    the access times? I haven't seen that, perhaps because I'm getting a=20
    segfault when I let a file play to the end. Here's the message the console =

    is giving:

    using configuration file: /opt/livesupport/etc/gLiveSupport.xml
    using config file '/opt/livesupport/etc/gLiveSupport.xml'
    ./gLiveSupport.sh: line 57: 17179 Aborted $gLiveSupport=5Fexe -c=20
    $config=5Ffile

    I'll be a lot more relieved if this behavior is something specific to my=20
    machine, rather than something more general with LS.


    doug








    =C1kos Mar=F3y
    08/29/05 02:15 PM
    Please respond to livesupport-dev

    =20
    To: livesupport-dev@campware.org
    cc:=20
    Subject: Re: [livesupport-dev] latest results


    Douglas.Arellanes@mdlf.org wrote:
    >=20
    > The playlists are all simple sequential playlists with default offsets.
    > Here is the breakdown:

    I did some experiments on my own. I made a playlist with four J.S. Bach
    files, totallying about 34 minutes. the opening time for this playlist
    is 0.7 seconds on my machine (1.8 GHz centrino)

    but, how are you opening the files?

    I tested trying to play them from the GUI scratchpad, and it indeed
    takes longer. but the time is not spent moslty on opening. the
    following calls are made then the play button is pressed in the=20
    scratchpad:


    cueItemPlayingNow =3D storage->acquirePlaylist(sessionId,
    playable->getId());
    cuePlayer->open(*cueItemPlayingNow->getUri());
    cuePlayer->start();


    the times for the above are:


    acquire duration: 00:00:01.389374
    open duration: 00:00:00.831224
    start duration: 00:00:00.044801


    so, most of the time spent is for acquiring the playlist from the
    storage. maybe we should open the files as soon as they appear in the
    scratchpad?


    how did you test these files? where / how did you play them?



    --=_alternative 0045766BC125706C_=
    Content-Type: text/html; charset="iso-8859-1"
    Content-Transfer-Encoding: quoted-printable



    I'm on a 1.1 Ghz PIII, and am openin=
    g the playlists by first putting an file in LS Studio Live Mode, then hitti=
    ng the 'stop' button, which should stop the current file playing and load t=
    he playlist in for playing. That's taking me 7-8 seconds after hitting the =
    'stop' button.




    Does waiting for a playlist item to =
    end officially make any difference in the access times? I haven't seen that=
    , perhaps because I'm getting a segfault when I let a file play to the end.=
    Here's the message the console is giving:




    using configuration file:  /opt=
    /livesupport/etc/gLiveSupport.xml


    using config file '/opt/livesupport/=
    etc/gLiveSupport.xml'


    ./gLiveSupport.sh: line 57: 17179 Ab=
    orted                 $gLiveSupport=
    =5Fexe -c $config=5Ffile




    I'll be a lot more relieved if this =
    behavior is something specific to my machine, rather than something more ge=
    neral with LS.






    doug

















    =C1kos Mar=F3y <darkeye@tyrell=
    .hu>

    08/29/05 02:15 PM

    Please respond to livesupport-dev ont>


           

            To: &nbs=
    p;      livesupport-dev@campware.org


            cc: &nbs=
    p;      


            Subject:=
           Re: [livesupport-dev] latest results
    ble>





    Douglas.Arellanes@mdlf.org wrote: r>
    >

    > The playlists are all simple sequential playlists with default offsets=
    .

    > Here is the breakdown:



    I did some experiments on my own. I made a playlist with four J.S. Bach

    files, totallying about 34 minutes. the opening time for this playlist

    is 0.7 seconds on my machine (1.8 GHz centrino)



    but, how are you opening the files?



    I tested trying to play them from the GUI scratchpad, and it indeed

    takes longer. but the time is not spent moslty on opening.  the

    following calls are made then the play button is pressed in the scratchpad:=






                   cueItemPlayingNow =
    =3D storage->acquirePlaylist(sessionId,

    playable->getId());

                   cuePlayer->open(=
    *cueItemPlayingNow->getUri());

                   cuePlayer->start=
    ();





    the times for the above are:





    acquire duration: 00:00:01.389374

    open duration: 00:00:00.831224

    start duration: 00:00:00.044801





    so, most of the time spent is for acquiring the playlist from the

    storage. maybe we should open the files as soon as they appear in the

    scratchpad?





    how did you test these files? where / how did you play them?






    --=_alternative 0045766BC125706C_=--

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Douglas.Arellanes@mdlf.org wrote:
    >
    > I'm on a 1.1 Ghz PIII, and am opening the playlists by first putting an
    > file in LS Studio Live Mode, then hitting the 'stop' button, which
    > should stop the current file playing and load the playlist in for
    > playing. That's taking me 7-8 seconds after hitting the 'stop' button.

    I tested my same Bach playlist in live mode as well. Basically it's the
    same procedure that happens when playing from the scratchpad. the times are:

    acquire duration: 00:00:01.176643
    open duration: 00:00:00.858749
    start duration: 00:00:00.044173


    this means that the most time is spent on opening the playlist and all
    related files. maybe Ferenc could optimize the process by opening files
    earlier (maybe as they are 'selected' in the scratchpad or anywhere else?).

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • Stefan de Konink wrote:
    > Is the parsing the actual problem or the reading process?

    it's a client-server achitecture, the files are accessed through XML-RPC
    from the storage server...

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • On Mon, 29 Aug 2005 16:29:11 +0200
  • Tomas Hlava wrote:
    > XML-RPC::locstor.accessRawAudioData

    XML-RPC is used, I guess accessRawAudioData

    but you can fire up the GUI, and then trace what calls are made. Doug
    can give you details on how to replicte the test scenario..


    Akos

    ------------------------------------------
    Posted to Phorum via PhorumMail
  • This is a multipart message in MIME format.
    --=_alternative 0058927CC125706C_=
    Content-Type: text/plain; charset="iso-8859-1"
    Content-Transfer-Encoding: quoted-printable

    The test files I've used are up on my site; I'm copying and pasting my=20
    previous mail here. The source materials are up on my site at=20
    http://www.arellanes.com/livesupport, but I'm sure that any MP3s or oggs=20
    at 128-192 kbps and 44.1 khz should be ok for testing. -- doug


    I'm on a 1.1 Ghz PIII, and am opening the playlists by first putting an=20
    file in LS Studio Live Mode, then hitting the 'stop' button, which should=20
    stop the current file playing and load the playlist in for playing. That's =

    taking me 7-8 seconds after hitting the 'stop' button.=20

    Does waiting for a playlist item to end officially make any difference in=20
    the access times? I haven't seen that, perhaps because I'm getting a=20
    segfault when I let a file play to the end. Here's the message the console =

    is giving:=20

    using configuration file: /opt/livesupport/etc/gLiveSupport.xml=20
    using config file '/opt/livesupport/etc/gLiveSupport.xml'=20
    ./gLiveSupport.sh: line 57: 17179 Aborted $gLiveSupport=5Fexe -c=20
    $config=5Ffile=20

    I'll be a lot more relieved if this behavior is something specific to my=20
    machine, rather than something more general with LS.=20





    I've tried some additional bitrates, but keeping the samplerate at=20
    44.1khz.=20

    Playlist: Donald Byrd (Duration: 45:44, 7 files, standard fades, all files =

    320kbps MP3); -- delay 8 sec.=20

    1. Street Lady 5:42=20
    2. Wind Parade 6:11=20
    3. Places and Spaces 6:22=20
    4. You and Music 5:23=20
    5. Flight Time 8:31=20
    6. Think Twice 6:13=20
    7. Blackbyrd 7:22=20

    For reference, files can be downloaded from http://www.arellanes.com/livesu=
    pport/test=5Ffiles/Donald Byrd - Best of Donald Byrd=20

    Playlist: Mashups (Duration: 25:25, 5 files, standard fades, all files=20
    256kbps MP3); -- delay 8 sec.=20
    1. Brazil is Full of Love 6:35=20
    2: Lick the Robot 4:11=20
    3. Jesus is my personal trainer 4:59=20
    4. Policy of Sweet Dreams 4:43=20
    5: Let Jolene Enjoy the Music In Silence 4:57=20

    for reference, these files can be downloaded from http://www.arellanes.com/=
    livesupport/earworm=20







    =C1kos Mar=F3y
    08/29/2005 06:04 PM
    Please respond to livesupport-dev

    =20
    To: livesupport-dev@campware.org
    cc:=20
    Subject: Re: [livesupport-dev] latest results


    Tomas Hlava wrote:
    > XML-RPC::locstor.accessRawAudioData

    XML-RPC is used, I guess accessRawAudioData

    but you can fire up the GUI, and then trace what calls are made. Doug
    can give you details on how to replicte the test scenario..


    Akos



    --=_alternative 0058927CC125706C_=
    Content-Type: text/html; charset="iso-8859-1"
    Content-Transfer-Encoding: quoted-printable



    The test files I've used are up on m=
    y site; I'm copying and pasting my previous mail here. The source materials=
    are up on my site at http://www.arellanes.com/livesupport, but I'm sure th=
    at any MP3s or oggs at 128-192 kbps and 44.1 khz should be ok for testing. =
    -- doug




    <snip>

    I'm on a 1.1 Ghz PIII, and am openin=
    g the playlists by first putting an file in LS Studio Live Mode, then hitti=
    ng the 'stop' button, which should stop the current file playing and load t=
    he playlist in for playing. That's taking me 7-8 seconds after hitting the =
    'stop' button.




    Does waiting for a playlist item to end officially make any difference in t=
    he access times? I haven't seen that, perhaps because I'm getting a segfaul=
    t when I let a file play to the end. Here's the message the console is givi=
    ng:




    using configuration file:  /opt/livesupport/etc/gLiveSupport.xml > s-serif">

    using config file '/opt/livesupport/etc/gLiveSupport.xml'
    =3D3 face=3D"Times New Roman"> r>
    ./gLiveSupport.sh: line 57: 17179 Aborted          =
    ;       $gLiveSupport=5Fexe -c $config=5Ffile
    ze=3D3 face=3D"Times New Roman">



    I'll be a lot more relieved if this behavior is something specific to my ma=
    chine, rather than something more general with LS.
    e=3D"Times New Roman">



    </snip>



    <snip>



    I've tried some additional bitrates,=
    but keeping the samplerate at 44.1khz.
    New Roman">



    Playlist: Donald Byrd (Duration: 45:44, 7 files, standard fades, all files =
    320kbps MP3); -- delay 8 sec.
    >



    1. Street Lady 5:42
    <=
    font size=3D2 face=3D"sans-serif">

    2. Wind Parade 6:11
    <=
    font size=3D2 face=3D"sans-serif">

    3. Places and Spaces 6:22 font>

    4. You and Music 5:23
    >

    5. Flight Time 8:31
    <=
    font size=3D2 face=3D"sans-serif">

    6. Think Twice 6:13
    <=
    font size=3D2 face=3D"sans-serif">

    7. Blackbyrd 7:22




    For reference, files can be downloaded from http://www.arellanes.com/livesu=
    pport/test=5Ffiles/Donald Byrd - Best of Donald Byrd
    ace=3D"Times New Roman">



    Playlist: Mashups (Duration: 25:25, 5 files, standard fades, all files 256k=
    bps MP3); -- delay 8 sec.
    font>

    1. Brazil is Full of Love 6:35
    ">

    2: Lick the Robot 4:11
    t>

    3. Jesus is my personal trainer 4:59
    Roman">

    4. Policy of Sweet Dreams 4:43
    ">

    5: Let Jolene Enjoy the Music In Silence 4:57
    Times New Roman">



    for reference, these files can be downloaded from http://www.arellanes.com/=
    livesupport/earworm




    </snip>











    =C1kos Mar=F3y <darkeye@tyrell=
    .hu>

    08/29/2005 06:04 PM

    Please respond to livesupport-dev ont>


           

            To: &nbs=
    p;      livesupport-dev@campware.org


            cc: &nbs=
    p;      


            Subject:=
           Re: [livesupport-dev] latest results
    ble>





    Tomas Hlava wrote:

    > XML-RPC::locstor.accessRawAudioData



    XML-RPC is used, I guess accessRawAudioData



    but you can fire up the GUI, and then trace what calls are made. Doug

    can give you details on how to replicte the test scenario..





    Akos






    --=_alternative 0058927CC125706C_=--

    ------------------------------------------
    Posted to Phorum via PhorumMail