Hey,
Another set of comments:
+ The interface feels a bit sluggish and I think that is because if you 'tab' between the 2 windows there is a visible refresh. I've been looking to get rid of it one way or the other but I struggle with ncurses.
+ One of my databases is /media/cdrom, even though pytone doesn't really take care of removable media, it works well. The only problem is that when it jumps to a new song and the new song happens to be on CD/DVD, the cross-fading stops (and the playback stops) until the CD/DVD has spun up. Usually a 1 or 2 second freeze :(
+ It would be nice if there was a global search facility. Something that is not context sensitive (like the 'j' option in xmms). A popup with all the results as you type.
+ Regarding the open()/close() versus seek()/truncate(), strace clearly shows that open()/close() costs more than seek()/truncate() (I'm not sure if the results is system dependent). But the win is just a small part of the overall of pytone.
+ It would be nice if someone more experienced with 'strace -f -c -p <pid of pytone>' during playback can comment on the immense ammount of futex time spend. I see 11 threads by default for 1 playback, most of the threads spend time in futex. I wonder why there need to be 11 threads ?
PS strace -f seems to be the problem, but you can strace individual threads to see where they spend the most time during playback. Any help in understanding this is welcome :)
PS2 But you can do strace -c -p <pid thread1> -p <pid thread2> ... to get a total picture..
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Hi,
On 13.05.05, Dag Wieers wrote:
Another set of comments:
- The interface feels a bit sluggish and I think that is because if you 'tab' between the 2 windows there is a visible refresh. I've been looking to get rid of it one way or the other but I struggle with ncurses.
Hmm, logging the calls of the doupdate function of the curses library shows only on call after pressing the TAB key.
- One of my databases is /media/cdrom, even though pytone doesn't really take care of removable media, it works well. The only problem is that when it jumps to a new song and the new song happens to be on CD/DVD, the cross-fading stops (and the playback stops) until the CD/DVD has spun up. Usually a 1 or 2 second freeze :(
Except from raising the buffer sizes of the output buffer, I don't see how to avoid this with the current player code. The reason for that is, that the player itself is not threaded (except for the audiodevice buffering), so when opening a new file for crossfading, a freeze can happen.
- It would be nice if there was a global search facility. Something that is not context sensitive (like the 'j' option in xmms). A popup with all the results as you type.
Yes, I also had this idea. But I wouldn't use a popup, but just show the results in the database window.
Regarding the open()/close() versus seek()/truncate(), strace clearly shows that open()/close() costs more than seek()/truncate() (I'm not sure if the results is system dependent). But the win is just a small part of the overall of pytone.
It would be nice if someone more experienced with 'strace -f -c -p <pid of pytone>' during playback can comment on the immense ammount of futex time spend. I see 11 threads by default for 1 playback, most of the threads spend time in futex. I wonder why there need to be 11 threads ?
Yes, there are many threads running: player(s), audiodevice buffer, database(s), database manager, playlist service, timer service, network service and of course the main UI thread. So at least you have 8 threads running... So PyTone is quite heavily threaded.
Jörg
On Tue, 17 May 2005, Joerg Lehmann wrote:
On 13.05.05, Dag Wieers wrote:
Another set of comments:
- The interface feels a bit sluggish and I think that is because if you 'tab' between the 2 windows there is a visible refresh. I've been looking to get rid of it one way or the other but I struggle with ncurses.
Hmm, logging the calls of the doupdate function of the curses library shows only on call after pressing the TAB key.
The refresh is probably worsened by the fact that it clears the area. I have been looking at other ncurses programs and they do not have this behaviour, so somehow it must be able to prevent this.
- It would be nice if there was a global search facility. Something that is not context sensitive (like the 'j' option in xmms). A popup with all the results as you type.
Yes, I also had this idea. But I wouldn't use a popup, but just show the results in the database window.
Well, having a popup would be nicer in the sense that you do not switch context and since it is find-as-you-type there is no need to stay in the results page when you have found what you were looking for. People are only interested in that one thing they were looking for, not in all the other results that their (imperfect) query returned.
That's why the xmms search functionality is brilliant and simple.
- It would be nice if someone more experienced with 'strace -f -c -p <pid of pytone>' during playback can comment on the immense ammount of futex time spend. I see 11 threads by default for 1 playback, most of the threads spend time in futex. I wonder why there need to be 11 threads ?
Yes, there are many threads running: player(s), audiodevice buffer, database(s), database manager, playlist service, timer service, network service and of course the main UI thread. So at least you have 8 threads running... So PyTone is quite heavily threaded.
My main concern was that each thread is doing plenty of futexes. I have no clue if this is normal at this rate and I also do not know if this is causing my pytone to consume >5% cpu-usage during playback on a 1.2Ghz laptop. Other music players consume considerably less CPU.
-- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Tue, 17 May 2005, Joerg Lehmann wrote:
On 13.05.05, Dag Wieers wrote:
Another set of comments:
- The interface feels a bit sluggish and I think that is because if you 'tab' between the 2 windows there is a visible refresh. I've been looking to get rid of it one way or the other but I struggle with ncurses.
Hmm, logging the calls of the doupdate function of the curses library shows only on call after pressing the TAB key.
After reading some curses documentation, they do explain that it's necessary to make all updates first on the virtual screen before calling doupdate(). But I'm not sure doupdate() is the problem here, is it possible something else is causing this ? Is the virtual terminal playing back operations instead of showing the result ?
What I see happening is that when pressing TAB to switch between the filelistwin and the playlistwin, the destination window (the one I'm switching to) is being cleared (the complete area) and redrawn.
I tested it with several terminal programs to ensure this was not a xterm problem. Am I the only one seeing this ? Because I think it's very disturbing (it makes pytone feel as slow and sluggish).
After a lot of trial and error I found a solution to the refresh even though I have no clue why this fixes it. I added the small patch to this mail. You may want to verify this and fix the real issue when found :)
Furthermore I have also seen cases where the initial screen is corrupted in the center of the screen. (something that is 2 chars high is removing part of the left border of the playlistwin) Pressing tab fixes the problem.
Can we expect a new (temporary) release that fixes these (and previous reported) issues ? Maybe with some contributed plugins inside the pytone tarball (shouldn't be a problem since you have to opt-in on each manually).
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On 28.05.05, Dag Wieers wrote:
On Tue, 17 May 2005, Joerg Lehmann wrote:
On 13.05.05, Dag Wieers wrote:
Another set of comments:
- The interface feels a bit sluggish and I think that is because if you 'tab' between the 2 windows there is a visible refresh. I've been looking to get rid of it one way or the other but I struggle with ncurses.
Hmm, logging the calls of the doupdate function of the curses library shows only on call after pressing the TAB key.
After reading some curses documentation, they do explain that it's necessary to make all updates first on the virtual screen before calling doupdate(). But I'm not sure doupdate() is the problem here, is it possible something else is causing this ? Is the virtual terminal playing back operations instead of showing the result ?
It should not. The doupdate() call should just copy the changed lines of the windows from the virtual screen to the actual screen. update_panels() on the other hand updates the said virtual screen for all existing panels. Actually it's a misnomer, since it does what wnoutrefresh() does for single windows, namely just updating the virtual screen. You can also call update_panels() more than once before the doupdate() call, but this should not change the result. Hence, I do not understand what your patch really does...
What I see happening is that when pressing TAB to switch between the filelistwin and the playlistwin, the destination window (the one I'm switching to) is being cleared (the complete area) and redrawn.
The frame of the window is touched when changing the focus (its attributes are changed). So maybe that's the reason, why the whole window is being redrawn. You may want to try changing in the config file the attributes of the activated window to be identical to the ones of the non-activated window.
I tested it with several terminal programs to ensure this was not a xterm problem. Am I the only one seeing this ? Because I think it's very disturbing (it makes pytone feel as slow and sluggish).
Here, I really do not see any sluggishness neither using konsole and xterm (on a four-year old notebook).
After a lot of trial and error I found a solution to the refresh even though I have no clue why this fixes it. I added the small patch to this mail. You may want to verify this and fix the real issue when found :)
As said above, I do not understand why this changes anything. Maybe somebody else has an idea. On the other hand, adding this call also doesn't harm, so...
Furthermore I have also seen cases where the initial screen is corrupted in the center of the screen. (something that is 2 chars high is removing part of the left border of the playlistwin) Pressing tab fixes the problem.
Hmm, does this come from a particular string (album/song title)?
Can we expect a new (temporary) release that fixes these (and previous reported) issues ? Maybe with some contributed plugins inside the pytone tarball (shouldn't be a problem since you have to opt-in on each manually).
Look here:
http://www.luga.de/pytone/download/PyTone-2.2.3+.tar.gz
Altough currently there is only one plugin (yours :-)). I have another nice plugin lying around on my computer, namely the AudioScrobbler interface posted some time ago by Nicolas Évrard. I did however not include it in the distributin, because I wanted him to specify the license of his code. Unfortunately, his email gateway seems to have some problems, so I did not yet get any answer from him. So Nicolas, if you're listening...
Jörg