rioplay-devel Mailing List for RioPlay - Audio player for Rio Receiver
Status: Beta
Brought to you by:
dbflower
You can subscribe to this list here.
2004 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(2) |
Jun
(2) |
Jul
(10) |
Aug
(4) |
Sep
|
Oct
|
Nov
(2) |
Dec
|
---|
From: Wim L. <wi...@us...> - 2004-11-24 04:00:35
|
On Tue, 23 Nov 2004, Wim Lewis wrote: > http://underhill.hhhh.org/viewcvs/rioplay/?sortdir=down Okay, this should actually be visible to the outside world now ... |
From: Wim L. <wi...@us...> - 2004-11-23 08:55:01
|
Since it doesn't look like anyone with write access to the sourceforge rioplay project is still involved in the project (and because I wanted to try out Subversion on a medium-size project) I've created a subversion repository to hold the things I've been doing with rioplay. If all is well you should be able to browse it at http://underhill.hhhh.org/viewcvs/rioplay/?sortdir=down Feel free to look around. The viewcvs I'm using seems to have trouble showing diffs between revisions, though. The URL probably isn't stable. If you have trouble getting to the repository let me know: I may have moved it or there may be a configuration problem. |
From: Ian P. <Ian...@co...> - 2004-08-24 04:37:31
|
Hi Lee, Thank you for your quick response and suggestions, but I am unsure if = they will help me. I will try to explain my situation a little better. At this point I am using the original server that came with the Rio = Receiver (armgr.exe) running on windows XP. The rio receiver code is = bundled up in a receiver.arf tar file. Contents as follows: drwxrwxr-x dave/dave 0 2003-01-12 18:35:18 ./ drwxrwxrwx root/root 0 2003-01-12 18:34:09 ./bin/ -rwxrwxr-x dave/dave 579100 2003-01-12 20:23:03 ./bin/rioplay drwxrwxrwx root/root 0 2002-08-26 21:10:13 ./dev/ crwxrwxrwx root/root 242,0 2002-08-20 18:31:31 ./dev/ir crwxrwxrwx root/root 245,3 2002-08-20 18:31:31 ./dev/dsp crwxrwxrwx root/root 1,1 2002-08-20 18:31:31 ./dev/mem crwxrwxrwx root/root 5,0 2002-08-20 18:31:31 ./dev/tty crwxrwxrwx root/root 1,2 2002-08-20 18:31:31 ./dev/kmem crwxrwxrwx root/root 1,3 2002-08-20 18:31:31 ./dev/null crwxrwxrwx root/root 1,5 2002-08-20 18:31:31 ./dev/zero lrwxrwxrwx root/root 0 2003-01-12 18:32:49 ./dev/console -> = ttyS0 crwxrwxrwx root/root 244,0 2002-08-20 18:31:31 ./dev/display crwxrwxrwx root/root 245,4 2002-08-20 18:31:31 ./dev/audio crwxrwxrwx root/root 245,0 2002-08-20 18:31:31 ./dev/mixer crwxrwxrwx root/root 4,64 2002-08-20 18:31:31 ./dev/ttyS0 crwxrwxrwx root/root 4,65 2002-08-20 18:31:31 ./dev/ttyS1 crwxrwxrwx root/root 1,8 2002-08-20 18:31:31 ./dev/random crwxrwxrwx root/root 1,9 2002-08-20 18:31:31 ./dev/urandom drwxrwxrwx root/root 0 2002-08-20 21:40:25 ./etc/ -rwxrwxrwx root/root 116 2002-06-23 05:44:43 ./etc/fstab -rwxrwxrwx root/root 2507 2002-08-20 21:45:45 ./etc/streams.cfg -rwxrwxrwx root/root 0 2002-06-23 05:44:44 ./etc/ld.so.conf -rwxrwxrwx root/root 2265 2002-06-23 05:44:44 ./etc/ld.so.cache -rwxrwxrwx root/root 43 2002-06-23 05:44:44 ./etc/resolv.conf drwxrwxrwx root/root 0 2002-07-18 16:17:19 ./lib/ -rwxrwxrwx dave/dave 163300 2002-07-18 16:17:19 ./lib/libm.so.6 -rwxrwxrwx dave/dave 88068 2002-07-18 16:17:19 ./lib/ld-linux.so.2 -rwxrwxrwx dave/dave 942292 2002-07-18 16:17:19 ./lib/libc.so.6 drwxrwxrwx root/root 0 2002-06-23 05:32:00 ./proc/ drwxrwxrwx root/root 0 2002-08-20 18:33:50 ./sbin/ -rwxrwxrwx root/root 3516 2002-09-07 07:39:22 ./sbin/init drwxrwxrwx root/root 0 2002-08-25 19:22:18 ./empeg/ drwxrwxrwx root/root 0 2002-08-25 19:22:20 ./empeg/lib/ drwxrwxrwx root/root 0 2002-08-25 19:24:13 ./empeg/lib/fonts/ -rwxrwxrwx root/root 9272 2002-08-25 19:24:24 = ./empeg/lib/fonts/medium.bf -rwxrwxrwx root/root 1264 2002-08-25 19:24:13 = ./empeg/lib/fonts/timecode.bf -rwxrwxrwx root/root 6500 2002-08-25 19:24:13 = ./empeg/lib/fonts/small.bf -rwxrwxrwx root/root 416 2002-08-25 19:24:13 = ./empeg/lib/fonts/wait.bf -rwxrwxrwx root/root 17588 2002-08-25 19:24:12 = ./empeg/lib/fonts/large.bf -rwxrwxrwx root/root 912 2002-08-25 19:24:12 = ./empeg/lib/fonts/graphics.bf -rwxrwxrwx root/root 48968 2002-09-06 22:58:39 ./il-binary.o -rwxrwxrwx root/root 393136 2002-09-06 22:58:09 ./zImage All I did was build the rioplay code as is (I did not change a thing), = then replaced the rioplay binary and init binary within the receiver.arf = with the ones I built (all on the Linux box). The server shows that the = mount is made and the zImage is downloaded, then rebooted. Then the = shared libraries are downloaded, then the init and rioplay binaries, but = then it goes into a loop requesting the rioplay binary again and again. My guess is an incompatibility between my built "init" and "rioplay" = binaries and the original zImage and shared libraries. So it looks like = I have 2 options: 1. Find the correct toolchain that matches the existing zImage and = shared libraries. 2. Build my own zImage. I have been avoiding this. I am really looking for opinions on the best way to go. If someone can = direct me to a better toolchain, that might help. Otherwise I will be = attempting to build my own zImage. I am determined to get this working, because I have a few changes I = would like to make. I have also begun making changes to the server code, = but that has been far easier than the embedded code. Thanks again, Ian ----- Original Message -----=20 From: lee=20 To: Ian Pedersen=20 Cc: rio...@li...=20 Sent: Sunday, August 22, 2004 8:41 PM Subject: Re: [Rioplay-devel] RioPlay question Or maybe it is the dot you are using I am confused by.=20 Here is a diff between two directory sub-rtee that work for me on = linux:=20 diff -r REAL RioPlay=20 Only in RioPlay/bin: rioplay=20 Only in REAL/dev: core=20 Only in REAL/empeg: bin=20 Binary files REAL/empeg/lib/fonts/medium.bf and = RioPlay/empeg/lib/fonts/medium.bf differ=20 Only in REAL/empeg/lib: lang=20 Only in RioPlay/etc: fstab=20 Only in RioPlay/etc: networks=20 Only in REAL/etc: nsswitch.conf=20 Only in REAL/etc: profile=20 Only in REAL/etc: protocols=20 Only in RioPlay/etc: resolv.conf=20 Only in RioPlay/etc: streams.cfg=20 Only in RioPlay/etc: sysconfig=20 Binary files REAL/il-binary.o and RioPlay/il-binary.o differ=20 Only in RioPlay: lib=20 Binary files REAL/sbin/init and RioPlay/sbin/init differ=20 Only in REAL: tmp=20 Binary files REAL/zImage and RioPlay/zImage differ=20 =20 Ian Pedersen wrote:=20 I am having trouble getting the RioPlay receiver code that I = compiled to run on the Rio Receiver. I struggled for a while to find the = correct toolchain and get an environment setup to compile the rioplay = code, but I believe I am now on the right track. I setup a box with = Debian Linux and installed Emdebian for an arm 2.95.2 cross-toolchain = environment. I was then able to compile the RioPlay code without any = problems. I replaced the './bin/rioplay' and './sbin/init' binaries = within a working receiver.arf, but the Rio Receiver does not like it. It = appears to go into an infinite loop. I traced the session with Ethereal = and saw the following LOOKUP call being mode over and over with = increasing XID value:NFS V2 LOOKUP Call XID 0xa2200000=20 NFS V2 LOOKUP Reply XID 0xa2200000=20 NFS V2 LOOKUP Call XID 0xa3200000=20 NFS V2 LOOKUP Reply XID 0xa3200000=20 NFS V2 LOOKUP Call XID 0xa4200000=20 NFS V2 LOOKUP Reply XID 0xa4200000=20 NFS V2 LOOKUP Call XID 0xa5200000=20 NFS V2 LOOKUP Reply XID 0xa5200000=20 ...etc Does anyone have any ideas what I might be doing wrong? Ian |
From: lee <le...@co...> - 2004-08-23 03:41:37
|
Or maybe it is the dot you are using I am confused by. Here is a diff between two directory sub-rtee that work for me on linux: diff -r REAL RioPlay Only in RioPlay/bin: rioplay Only in REAL/dev: core Only in REAL/empeg: bin Binary files REAL/empeg/lib/fonts/medium.bf and RioPlay/empeg/lib/fonts/medium.bf differ Only in REAL/empeg/lib: lang Only in RioPlay/etc: fstab Only in RioPlay/etc: networks Only in REAL/etc: nsswitch.conf Only in REAL/etc: profile Only in REAL/etc: protocols Only in RioPlay/etc: resolv.conf Only in RioPlay/etc: streams.cfg Only in RioPlay/etc: sysconfig Binary files REAL/il-binary.o and RioPlay/il-binary.o differ Only in RioPlay: lib Binary files REAL/sbin/init and RioPlay/sbin/init differ Only in REAL: tmp Binary files REAL/zImage and RioPlay/zImage differ Ian Pedersen wrote: > I am having trouble getting the RioPlay receiver code that I compiled > to run on the Rio Receiver. I struggled for a while to find the > correct toolchain and get an environment setup to compile the rioplay > code, but I believe I am now on the right track. I setup a box with > Debian Linux and installed Emdebian for an arm 2.95.2 cross-toolchain > environment. I was then able to compile the RioPlay code without any > problems. I replaced the './bin/rioplay' and './sbin/init' binaries > within a working receiver.arf, but the Rio Receiver does not like it. > It appears to go into an infinite loop. I traced the session with > Ethereal and saw the following LOOKUP call being mode over and over > with increasing XID value:NFS V2 LOOKUP Call XID 0xa2200000 > NFS V2 LOOKUP Reply XID 0xa2200000 > NFS V2 LOOKUP Call XID 0xa3200000 > NFS V2 LOOKUP Reply XID 0xa3200000 > NFS V2 LOOKUP Call XID 0xa4200000 > NFS V2 LOOKUP Reply XID 0xa4200000 > NFS V2 LOOKUP Call XID 0xa5200000 > NFS V2 LOOKUP Reply XID 0xa5200000 > ...etc Does anyone have any ideas what I might be doing wrong? Ian |
From: lee <le...@co...> - 2004-08-23 03:34:37
|
Dunno nfs internal protcols, but the directory nfs tries to mount is: /tftpboot/xxx.xxx.xxx.xxx where xxx.xxx.xxx.xxx is the ip # of the rio box (and note leading slash - I do mean root) Ian Pedersen wrote: > I am having trouble getting the RioPlay receiver code that I compiled > to run on the Rio Receiver. I struggled for a while to find the > correct toolchain and get an environment setup to compile the rioplay > code, but I believe I am now on the right track. I setup a box with > Debian Linux and installed Emdebian for an arm 2.95.2 cross-toolchain > environment. I was then able to compile the RioPlay code without any > problems. I replaced the './bin/rioplay' and './sbin/init' binaries > within a working receiver.arf, but the Rio Receiver does not like it. > It appears to go into an infinite loop. I traced the session with > Ethereal and saw the following LOOKUP call being mode over and over > with increasing XID value:NFS V2 LOOKUP Call XID 0xa2200000 > NFS V2 LOOKUP Reply XID 0xa2200000 > NFS V2 LOOKUP Call XID 0xa3200000 > NFS V2 LOOKUP Reply XID 0xa3200000 > NFS V2 LOOKUP Call XID 0xa4200000 > NFS V2 LOOKUP Reply XID 0xa4200000 > NFS V2 LOOKUP Call XID 0xa5200000 > NFS V2 LOOKUP Reply XID 0xa5200000 > ...etc Does anyone have any ideas what I might be doing wrong? Ian |
From: Ian P. <ia...@ho...> - 2004-08-22 22:54:45
|
I am having trouble getting the RioPlay receiver code that I compiled to = run on the Rio Receiver. I struggled for a while to find the correct = toolchain and get an environment setup to compile the rioplay code, but = I believe I am now on the right track. I setup a box with Debian Linux = and installed Emdebian for an arm 2.95.2 cross-toolchain environment. I = was then able to compile the RioPlay code without any problems. I = replaced the './bin/rioplay' and './sbin/init' binaries within a working = receiver.arf, but the Rio Receiver does not like it. It appears to go = into an infinite loop. I traced the session with Ethereal and saw the = following LOOKUP call being mode over and over with increasing XID = value: NFS V2 LOOKUP Call XID 0xa2200000 NFS V2 LOOKUP Reply XID 0xa2200000 NFS V2 LOOKUP Call XID 0xa3200000 NFS V2 LOOKUP Reply XID 0xa3200000 NFS V2 LOOKUP Call XID 0xa4200000 NFS V2 LOOKUP Reply XID 0xa4200000 NFS V2 LOOKUP Call XID 0xa5200000 NFS V2 LOOKUP Reply XID 0xa5200000 ..etc Does anyone have any ideas what I might be doing wrong? Ian |
From: Wim L. <wi...@us...> - 2004-07-27 05:44:20
|
On Wed, 21 Jul 2004, Wim Lewis wrote: > I'm guessing that the memory use can be accounted for by: > - a few copies of each track name in different lists here and > there (the input source, the menu screen...) I made some fairly minor changes to the code --- mostly just changing the way string parameters are passed around, and I changed some 'vector's into 'rope's --- which bumped the limit to around 45,000 tracks before the rioplay process would die from lack of memory. That's about triple what it was, which makes sense; I noticed that there were at least three copies of each string being made in the old code, but now they should all be sharing the same refcounted buffer. OTOH, it takes a noticeably long time to transfer 45,000 tracks to the player, and this happens each time you go to the menu. So any further towards supporting large libraries probably ought to focus on allowing partial fetches. But for a small change, this made a pretty large difference... Wim. |
From: lee <le...@co...> - 2004-07-22 17:49:10
|
Requests on the fly apporach is defintitely the ideal (4th Dimension database does that). I'm was, and still am, looking at not changing the client, and using server "tricks" to do. Dan Conti wrote: > As you flip through the UI, when you get within 5 results of the end > of your data, you send a new query for the next 20 results. You could > do this using a sort of ping-pong list scheme, so that if the UI was > on track 30 overall, list a would have tracks 1-20, and list b would > have tracks 21-40; when you got to track 35, list a would have tracks > 41-60, and list b tracks 21-40. Assuming the device can gracefully > query in the background (which it should be able to do), this lets you > greatly reduce the memory footprint. I dont remember how the query > stuff works in rioplay, but it seems like you could just pass off > whichever list you aren't browsing to the query engine for it to > populate... > > Making the lists static/fixed length strings would be way better than > using malloc, STL, or any of the other options available here. Chances > are the server software has a limit of sorts to start out with, and > even if you set up 256 bytes per entry, with 40 entries that is only > 10k of fixed memory. > > -----Original Message----- > From: rio...@li... > [mailto:rio...@li...]On Behalf > Of lee > Sent: Thursday, July 22, 2004 8:49 AM > To: Wim Lewis > Cc: Rio...@li... > Subject: Re: [Rioplay-devel] Rioplay and memory usage > > Certainly working with the server is easier than the client. > > One theortical way is: > The server watches how long its reply is getting. Limits it > and adds "next and prev links". > > The problem is the client which is far from a generic web > browser. >From the Songs/Titles/Artist lists it is easy to > send next/prev request - evenit is only sending a dummy > "title" or id. Getting the server to do the right thing is > easy. But how the client handles this 2nd reply is the > problem. > > > Wim Lewis wrote: > > > > > Out of curiosity, how big is big? Tens of thousands of > > tracks? Millions? > > > Only 820 tracks. > > > > Right, I'd forgotten that the player really doesn't have > > much RAM (and no > > swap :-) ). > > > > I modified rioplay's status webpage to report some memory > > information > > (/proc/meminfo and the results of a mallinfo() call) so > > that I can watch > > it as I run the program. The rioplay process starts out > > with about 50k of > > heap, and the kernel reports ~700k of free memory > > according to meminfo. > > > > Interestingly the rioplay memory usage goes up by a few > > pages (4-12 kB) > > each time I look at a listing, but this eventually levels > > off so I > > assume it's fragmentation rather than an actual memory > > leak. > > > > I then modified the perl scripts I use on the server to > > return a number of > > extra entries on each query. At around 600 (total) entries > > the player's UI > > started to get noticeably slow, but it didn't actually > > crash until after > > 10,000 entries (it succeeded with 10150 or so, and the > > next number I tried > > was 15150, which reliably causes the rioplay process to > > spew some malloc > > warnings and then exit. It is gracefully restarted by > > init, though, which > > is nice.) > > > > The difference between this number and 871 is probably > > partly due to the > > fact that my extra tracks have pretty short names (10 > > characters or so). > > I'm guessing that the memory use can be accounted for by: > > - a few copies of each track name in different lists > > here and > > there (the input source, the menu screen...) > > - memory fragmentation > > - malloc overhead > > > > Looking through the code, I notice that it uses a mixture > > of C-style > > char*-and-malloc strings and C++ STL strings. It seems to > > me that a lot of > > memory could be saved by using immutable STL strings > > throughout, since > > copies of strings can share their storage > > behind-the-scenes, but only if > > they don't go through a char* stage in between. Changing > > some of the > > vectors and arrays to lists or ropes (also available in > > the g++ STL) ought > > to reduce the heap fragmentation a bit, as well. I'll give > > this a try the > > next time I have a few days to tinker with it. > > > > Dan Conti writes: > > > Personally i use[d] a perl package called mserve for > > serving content. It > > > should be easy to modify this to support query ranges, > > such that you do: > > > > I'm also using a perl script loosely based on Jeff Mock's > > perl server > > script and I've noticed it already has the beginning of > > support for begin= > > and end= parameters on queries. Do you know if this is in > > there to support > > the original player software, or if it's an unfinished > > experimental > > feature? > > > > Of course, since at this point both the client and the > > server are > > open-source and under my control, there's no real reason I > > can't add > > another InputSource subclass and move to a different > > protocol entirely. I > > wonder if there's an existing protocol that would fit the > > bill, maybe > > Apple's (officially-undocumented) DAAP protocol? > > > > > Makes me wish i had more time to work on such things. > > Best of luck with your > > > projects :) > > > > Yes, I'm hoping I'll actually get this to an interesting > > point before > > getting distracted by the rest of my life again :-) > > > > Wim. > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by BEA Weblogic Workshop > > FREE Java Enterprise J2EE developer tools! > > Get your free copy of BEA WebLogic Workshop 8.1 today. > > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > > _______________________________________________ > > Rioplay-devel mailing list > > Rio...@li... > > https://lists.sourceforge.net/lists/listinfo/rioplay-devel > |
From: Dan C. <dc...@ac...> - 2004-07-22 16:02:01
|
As you flip through the UI, when you get within 5 results of the end of your data, you send a new query for the next 20 results. You could do this using a sort of ping-pong list scheme, so that if the UI was on track 30 overall, list a would have tracks 1-20, and list b would have tracks 21-40; when you got to track 35, list a would have tracks 41-60, and list b tracks 21-40. Assuming the device can gracefully query in the background (which it should be able to do), this lets you greatly reduce the memory footprint. I dont remember how the query stuff works in rioplay, but it seems like you could just pass off whichever list you aren't browsing to the query engine for it to populate... Making the lists static/fixed length strings would be way better than using malloc, STL, or any of the other options available here. Chances are the server software has a limit of sorts to start out with, and even if you set up 256 bytes per entry, with 40 entries that is only 10k of fixed memory. -----Original Message----- From: rio...@li... [mailto:rio...@li...]On Behalf Of lee Sent: Thursday, July 22, 2004 8:49 AM To: Wim Lewis Cc: Rio...@li... Subject: Re: [Rioplay-devel] Rioplay and memory usage Certainly working with the server is easier than the client. One theortical way is: The server watches how long its reply is getting. Limits it and adds "next and prev links". The problem is the client which is far from a generic web browser. >From the Songs/Titles/Artist lists it is easy to send next/prev request - evenit is only sending a dummy "title" or id. Getting the server to do the right thing is easy. But how the client handles this 2nd reply is the problem. Wim Lewis wrote: > > Out of curiosity, how big is big? Tens of thousands of tracks? Millions? > Only 820 tracks. Right, I'd forgotten that the player really doesn't have much RAM (and no swap :-) ). I modified rioplay's status webpage to report some memory information (/proc/meminfo and the results of a mallinfo() call) so that I can watch it as I run the program. The rioplay process starts out with about 50k of heap, and the kernel reports ~700k of free memory according to meminfo. Interestingly the rioplay memory usage goes up by a few pages (4-12 kB) each time I look at a listing, but this eventually levels off so I assume it's fragmentation rather than an actual memory leak. I then modified the perl scripts I use on the server to return a number of extra entries on each query. At around 600 (total) entries the player's UI started to get noticeably slow, but it didn't actually crash until after 10,000 entries (it succeeded with 10150 or so, and the next number I tried was 15150, which reliably causes the rioplay process to spew some malloc warnings and then exit. It is gracefully restarted by init, though, which is nice.) The difference between this number and 871 is probably partly due to the fact that my extra tracks have pretty short names (10 characters or so). I'm guessing that the memory use can be accounted for by: - a few copies of each track name in different lists here and there (the input source, the menu screen...) - memory fragmentation - malloc overhead Looking through the code, I notice that it uses a mixture of C-style char*-and-malloc strings and C++ STL strings. It seems to me that a lot of memory could be saved by using immutable STL strings throughout, since copies of strings can share their storage behind-the-scenes, but only if they don't go through a char* stage in between. Changing some of the vectors and arrays to lists or ropes (also available in the g++ STL) ought to reduce the heap fragmentation a bit, as well. I'll give this a try the next time I have a few days to tinker with it. Dan Conti writes: > Personally i use[d] a perl package called mserve for serving content. It > should be easy to modify this to support query ranges, such that you do: I'm also using a perl script loosely based on Jeff Mock's perl server script and I've noticed it already has the beginning of support for begin= and end= parameters on queries. Do you know if this is in there to support the original player software, or if it's an unfinished experimental feature? Of course, since at this point both the client and the server are open-source and under my control, there's no real reason I can't add another InputSource subclass and move to a different protocol entirely. I wonder if there's an existing protocol that would fit the bill, maybe Apple's (officially-undocumented) DAAP protocol? > Makes me wish i had more time to work on such things. Best of luck with your > projects :) Yes, I'm hoping I'll actually get this to an interesting point before getting distracted by the rest of my life again :-) Wim. ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ Rioplay-devel mailing list Rio...@li... https://lists.sourceforge.net/lists/listinfo/rioplay-devel |
From: lee <le...@co...> - 2004-07-22 15:49:03
|
Certainly working with the server is easier than the client. One theortical way is: The server watches how long its reply is getting. Limits it and adds "next and prev links". The problem is the client which is far from a generic web browser. From the Songs/Titles/Artist lists it is easy to send next/prev request - evenit is only sending a dummy "title" or id. Getting the server to do the right thing is easy. But how the client handles this 2nd reply is the problem. Wim Lewis wrote: > > > Out of curiosity, how big is big? Tens of thousands of tracks? Millions? > > Only 820 tracks. > > Right, I'd forgotten that the player really doesn't have much RAM (and no > swap :-) ). > > I modified rioplay's status webpage to report some memory information > (/proc/meminfo and the results of a mallinfo() call) so that I can watch > it as I run the program. The rioplay process starts out with about 50k of > heap, and the kernel reports ~700k of free memory according to meminfo. > > Interestingly the rioplay memory usage goes up by a few pages (4-12 kB) > each time I look at a listing, but this eventually levels off so I > assume it's fragmentation rather than an actual memory leak. > > I then modified the perl scripts I use on the server to return a number of > extra entries on each query. At around 600 (total) entries the player's UI > started to get noticeably slow, but it didn't actually crash until after > 10,000 entries (it succeeded with 10150 or so, and the next number I tried > was 15150, which reliably causes the rioplay process to spew some malloc > warnings and then exit. It is gracefully restarted by init, though, which > is nice.) > > The difference between this number and 871 is probably partly due to the > fact that my extra tracks have pretty short names (10 characters or so). > I'm guessing that the memory use can be accounted for by: > - a few copies of each track name in different lists here and > there (the input source, the menu screen...) > - memory fragmentation > - malloc overhead > > Looking through the code, I notice that it uses a mixture of C-style > char*-and-malloc strings and C++ STL strings. It seems to me that a lot of > memory could be saved by using immutable STL strings throughout, since > copies of strings can share their storage behind-the-scenes, but only if > they don't go through a char* stage in between. Changing some of the > vectors and arrays to lists or ropes (also available in the g++ STL) ought > to reduce the heap fragmentation a bit, as well. I'll give this a try the > next time I have a few days to tinker with it. > > Dan Conti writes: > > Personally i use[d] a perl package called mserve for serving content. It > > should be easy to modify this to support query ranges, such that you do: > > I'm also using a perl script loosely based on Jeff Mock's perl server > script and I've noticed it already has the beginning of support for begin= > and end= parameters on queries. Do you know if this is in there to support > the original player software, or if it's an unfinished experimental > feature? > > Of course, since at this point both the client and the server are > open-source and under my control, there's no real reason I can't add > another InputSource subclass and move to a different protocol entirely. I > wonder if there's an existing protocol that would fit the bill, maybe > Apple's (officially-undocumented) DAAP protocol? > > > Makes me wish i had more time to work on such things. Best of luck with your > > projects :) > > Yes, I'm hoping I'll actually get this to an interesting point before > getting distracted by the rest of my life again :-) > > Wim. > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Rioplay-devel mailing list > Rio...@li... > https://lists.sourceforge.net/lists/listinfo/rioplay-devel |
From: Wim L. <wi...@us...> - 2004-07-21 20:57:24
|
> > Out of curiosity, how big is big? Tens of thousands of tracks? Millions? > Only 820 tracks. Right, I'd forgotten that the player really doesn't have much RAM (and no swap :-) ). I modified rioplay's status webpage to report some memory information (/proc/meminfo and the results of a mallinfo() call) so that I can watch it as I run the program. The rioplay process starts out with about 50k of heap, and the kernel reports ~700k of free memory according to meminfo. Interestingly the rioplay memory usage goes up by a few pages (4-12 kB) each time I look at a listing, but this eventually levels off so I assume it's fragmentation rather than an actual memory leak. I then modified the perl scripts I use on the server to return a number of extra entries on each query. At around 600 (total) entries the player's UI started to get noticeably slow, but it didn't actually crash until after 10,000 entries (it succeeded with 10150 or so, and the next number I tried was 15150, which reliably causes the rioplay process to spew some malloc warnings and then exit. It is gracefully restarted by init, though, which is nice.) The difference between this number and 871 is probably partly due to the fact that my extra tracks have pretty short names (10 characters or so). I'm guessing that the memory use can be accounted for by: - a few copies of each track name in different lists here and there (the input source, the menu screen...) - memory fragmentation - malloc overhead Looking through the code, I notice that it uses a mixture of C-style char*-and-malloc strings and C++ STL strings. It seems to me that a lot of memory could be saved by using immutable STL strings throughout, since copies of strings can share their storage behind-the-scenes, but only if they don't go through a char* stage in between. Changing some of the vectors and arrays to lists or ropes (also available in the g++ STL) ought to reduce the heap fragmentation a bit, as well. I'll give this a try the next time I have a few days to tinker with it. Dan Conti writes: > Personally i use[d] a perl package called mserve for serving content. It > should be easy to modify this to support query ranges, such that you do: I'm also using a perl script loosely based on Jeff Mock's perl server script and I've noticed it already has the beginning of support for begin= and end= parameters on queries. Do you know if this is in there to support the original player software, or if it's an unfinished experimental feature? Of course, since at this point both the client and the server are open-source and under my control, there's no real reason I can't add another InputSource subclass and move to a different protocol entirely. I wonder if there's an existing protocol that would fit the bill, maybe Apple's (officially-undocumented) DAAP protocol? > Makes me wish i had more time to work on such things. Best of luck with your > projects :) Yes, I'm hoping I'll actually get this to an interesting point before getting distracted by the rest of my life again :-) Wim. |
From: lee <le...@co...> - 2004-07-19 21:26:45
|
I think I can maintain backwards compatibilty. I'm planning on putting something in the reply to one of the players inital requests, that I can parse and recognise "hey -new style server" or not. So I can maintain backwards compatibilty with very little code. Time is the issue. I don't have it right now. - Lee Weston Dan Conti wrote: > > -----Original Message----- > > [mailto:rio...@li...]On Behalf Of Wim Lewis > > Sent: Thursday, July 15, 2004 8:01 PM > > Subject: Re: [Rioplay-devel] Tweaking rioplay > > > > Having looked at it a little but not actually started coding, I don't > > think it would be too hard to implement in a way that's kind of like the > > way the display handles overlays. The audio output driver would have a > > main output stream, which might be interrupted by a higher-priority > > stream. The output buffer size is pretty small so it wouldn't have to > > worry about huge amounts of latency or anything like that. To the codecs > > (etc.) these might look like multiple separate audio output devices. > > There are two basic strategies here: > > 1) Create a mixing object, which can handle audio from multiple sources and > generates a single output; hook this output up to the audio driver > > 2) Do a non-mixing switch, such that audio comes from either one source or > the other; this is closer to what you are describing > > The second is far easier. Still, you will have to answer things like "what > do you do if you interject a sound snippet that ends in the middle of a > buffer". If you are just doing beeping noises it's probably a non issue > since you can control the length. > > On the alarm clock issue, i actually started working on this, but kinda gave > up. My idea was to do a clock-radio type of setup, where you could select > content to play when the alarm goes off. Unfortunately none of the > content-querying stuff is set up to work like that, and i had a few other > projects that were more interesting at the time. > > > > My goal remains: make it work with big collections of music. > > > My Rio crashes on a bunch of menus, because my music collection > > is too big > > > (both with RioPlay and the original Rio software). > > > > Out of curiosity, how big is big? Tens of thousands of tracks? Millions? > > The content querying stuff is pretty brain dead, and the device doesn't have > a lot of memory; if you query for "artists" the server will send it all > back, and rioplay will choke. > > Personally i use[d] a perl package called mserve for serving content. It > should be easy to modify this to support query ranges, such that you do: > > GET http://.../query?artist=&start=1&end=20 > > And then make new queries from the device for subsequent ranges as the user > steps through the menus, or as they play through a given playlist. Part of > this assumes you can do a query like: > > GET http://.../query?artist=&count=1 > > To just get a total number of artists. But this breaks compatibility with > the protocol. > > Makes me wish i had more time to work on such things. Best of luck with your > projects :) > > -Dan > |
From: Wim L. <wi...@us...> - 2004-07-18 03:24:07
|
On Fri, 16 Jul 2004, Dan Conti wrote: > The second is far easier. Still, you will have to answer things like "what > do you do if you interject a sound snippet that ends in the middle of a > buffer". If you are just doing beeping noises it's probably a non issue > since you can control the length. The buffers are pretty short --- 4608 bytes of 16-bit stereo sound, which translates to only (1152 * 1/44100) = about 26 milliseconds. So it seems like it would be OK to just pad things out to the next 26-ms boundary with silence. FWIW, when I posted last month, I got a response from <tony> at xplhal.com, saying that he'd already implemented the sound-interjection feature in xplhal's fork of the rioplay code. I've downloaded a tarfile from the website but it looks like it's an older version of the source --- I haven't dug around to find a more up-to-date one yet. |
From: Dan C. <dc...@ac...> - 2004-07-17 03:13:12
|
> -----Original Message----- > [mailto:rio...@li...]On Behalf Of Wim Lewis > Sent: Thursday, July 15, 2004 8:01 PM > Subject: Re: [Rioplay-devel] Tweaking rioplay > > Having looked at it a little but not actually started coding, I don't > think it would be too hard to implement in a way that's kind of like the > way the display handles overlays. The audio output driver would have a > main output stream, which might be interrupted by a higher-priority > stream. The output buffer size is pretty small so it wouldn't have to > worry about huge amounts of latency or anything like that. To the codecs > (etc.) these might look like multiple separate audio output devices. There are two basic strategies here: 1) Create a mixing object, which can handle audio from multiple sources and generates a single output; hook this output up to the audio driver 2) Do a non-mixing switch, such that audio comes from either one source or the other; this is closer to what you are describing The second is far easier. Still, you will have to answer things like "what do you do if you interject a sound snippet that ends in the middle of a buffer". If you are just doing beeping noises it's probably a non issue since you can control the length. On the alarm clock issue, i actually started working on this, but kinda gave up. My idea was to do a clock-radio type of setup, where you could select content to play when the alarm goes off. Unfortunately none of the content-querying stuff is set up to work like that, and i had a few other projects that were more interesting at the time. > > My goal remains: make it work with big collections of music. > > My Rio crashes on a bunch of menus, because my music collection > is too big > > (both with RioPlay and the original Rio software). > > Out of curiosity, how big is big? Tens of thousands of tracks? Millions? The content querying stuff is pretty brain dead, and the device doesn't have a lot of memory; if you query for "artists" the server will send it all back, and rioplay will choke. Personally i use[d] a perl package called mserve for serving content. It should be easy to modify this to support query ranges, such that you do: GET http://.../query?artist=&start=1&end=20 And then make new queries from the device for subsequent ranges as the user steps through the menus, or as they play through a given playlist. Part of this assumes you can do a query like: GET http://.../query?artist=&count=1 To just get a total number of artists. But this breaks compatibility with the protocol. Makes me wish i had more time to work on such things. Best of luck with your projects :) -Dan > > > On a related note: is anyone with commit access reading this list? I have > some changes I'd like to submit back to the project (including a fix for > an annoying crash in the http code). > > Wim. > > > > ------------------------------------------------------- > This SF.Net email is sponsored by BEA Weblogic Workshop > FREE Java Enterprise J2EE developer tools! > Get your free copy of BEA WebLogic Workshop 8.1 today. > http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click > _______________________________________________ > Rioplay-devel mailing list > Rio...@li... > https://lists.sourceforge.net/lists/listinfo/rioplay-devel |
From: lee <le...@co...> - 2004-07-16 15:32:44
|
Wim Lewis wrote: > On Mon, 7 Jun 2004, lee wrote: > > Wim Lewis wrote: > > > The other is to provide a way to interject a snippet of sound into the > > > audio being played ... > > > > I think you are going to find that rough to do because of the way the sound > > library works. > > Having looked at it a little but not actually started coding, I don't > think it would be too hard to implement in a way that's kind of like the > way the display handles overlays. The audio output driver would have a > main output stream, which might be interrupted by a higher-priority > stream. The output buffer size is pretty small so it wouldn't have to > worry about huge amounts of latency or anything like that. To the codecs > (etc.) these might look like multiple separate audio output devices. > > > My goal remains: make it work with big collections of music. > > My Rio crashes on a bunch of menus, because my music collection is too big > > (both with RioPlay and the original Rio software). > > Out of curiosity, how big is big? Tens of thousands of tracks? Millions? Only 820 tracks. > > > On a related note: is anyone with commit access reading this list? I have > some changes I'd like to submit back to the project (including a fix for > an annoying crash in the http code). > > Wim. > |
From: Wim L. <wi...@us...> - 2004-07-16 03:01:10
|
On Mon, 7 Jun 2004, lee wrote: > Wim Lewis wrote: > > The other is to provide a way to interject a snippet of sound into the > > audio being played ... > > I think you are going to find that rough to do because of the way the sound > library works. Having looked at it a little but not actually started coding, I don't think it would be too hard to implement in a way that's kind of like the way the display handles overlays. The audio output driver would have a main output stream, which might be interrupted by a higher-priority stream. The output buffer size is pretty small so it wouldn't have to worry about huge amounts of latency or anything like that. To the codecs (etc.) these might look like multiple separate audio output devices. > My goal remains: make it work with big collections of music. > My Rio crashes on a bunch of menus, because my music collection is too big > (both with RioPlay and the original Rio software). Out of curiosity, how big is big? Tens of thousands of tracks? Millions? On a related note: is anyone with commit access reading this list? I have some changes I'd like to submit back to the project (including a fix for an annoying crash in the http code). Wim. |
From: lee <le...@co...> - 2004-06-07 15:58:06
|
Wim Lewis wrote: > The other is to provide a way to interject a snippet of sound into the > audio being played ... since the Rio never really turns off, it could be > used for general audio alerts, or as an alarm clock, or whatever. (Mostly > it just seems like a Neat Idea.) > I think you are going to find that rough to do because of the way the sound library works. > Lee, have you tried compiling the toolchain yourself? It's a hassle but > it's possible. :-) > No. All heck has broken loose around here. Still on my list, but not before July 17. My goal remains: make it work with big collections of music. My Rio crashes on a bunch of menus, because my music collection is too big (both with RioPlay and the original Rio software). Then maybe backport it to the original Cirrus development board (I picked up a used one). Then the real fun begins. |
From: Wim L. <wi...@hh...> - 2004-06-06 00:32:59
|
After far too much trouble, I finally got a cross-build environment set up on my BSD box and can compile executables for the Rio. I've been making small changes here and there, mostly to make sure that I understand how it all fits together. I'm interested in adding a couple of things to the software. One is to provide a richer interface to the playlist, maybe web-based or maybe with a small companion program. If I happen to be sitting by a computer, it would be nice to have the full keyboard and screen available for selecting music. The other is to provide a way to interject a snippet of sound into the audio being played ... since the Rio never really turns off, it could be used for general audio alerts, or as an alarm clock, or whatever. (Mostly it just seems like a Neat Idea.) Since it's been pretty quiet on this list, I thought I'd post and see if anyone else is up to anything. (For the curious, the problem I was having cross-compiling was that I could build the first (C-only) gcc, and then glibc, but building the second, C++-capable gcc would fail while compiling libiberty for libstdc++. The problem was that the libc.so installed by glibc was actually a brief linker script, and that linker script contained a pathname to the real libc that was incorrect. Fixing the pathname fixed the problem.) Lee, have you tried compiling the toolchain yourself? It's a hassle but it's possible. :-) |
From: <ben...@id...> - 2004-05-25 08:46:29
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
From: lee <le...@co...> - 2004-05-16 23:46:16
|
I am still looking for a toolchain so I can make changes and compile RioPlay? Anyone know where I can find a toolchain? lee wrote: > I had. The link is still there - but not the file. > > Paul Noffke wrote: > > > Have you looked at http://www.mock.com/receiver/tools/ ? > |
From: lee <le...@co...> - 2004-04-22 20:37:53
|
I had. The link is still there - but not the file. Paul Noffke wrote: > Have you looked at http://www.mock.com/receiver/tools/ ? > |
From: Paul N. <pa...@mi...> - 2004-04-20 16:57:09
|
Have you looked at http://www.mock.com/receiver/tools/ ? -----Original Message----- From: rio...@li... [mailto:rio...@li...] On Behalf Of rio...@li... Sent: 20 April 2004 04:06 To: rio...@li... Subject: Rioplay-devel digest, Vol 1 #1 - 1 msg Send Rioplay-devel mailing list submissions to rio...@li... To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/rioplay-devel or, via email, send a message with subject or body 'help' to rio...@li... You can reach the person managing the list at rio...@li... When replying, please edit your Subject line so it is more specific than "Re: Contents of Rioplay-devel digest..." Today's Topics: 1. toolchain (lee) --__--__-- Message: 1 Date: Mon, 19 Apr 2004 12:06:12 -0400 From: lee <le...@co...> To: rio...@li... Subject: [Rioplay-devel] toolchain I'm looking for a toolchain to build RioPlay. --__--__-- _______________________________________________ Rioplay-devel mailing list Rio...@li... https://lists.sourceforge.net/lists/listinfo/rioplay-devel End of Rioplay-devel Digest |
From: lee <le...@co...> - 2004-04-19 16:06:33
|
I'm looking for a toolchain to build RioPlay. |