Menu
▾
▴
cdrdao-devel
|
From: Manuel C. <ll...@ja...> - 2001-08-04 01:10:24
|
Hi all, Here is what I just commited to CVS: * Changed the play/stop button to a "play | stop" toolbar, this prevents the "playing again" problem when you hit the button twice to stop the playing and it starts again... * moved the play and playCallback funcs to AudioCDProject * added a playStop func to audioCDView and AudioCDProject * got some icons from tcd for the play toolbar * AudioCDView is no more a friendly class of AudioCDChild (read: removed bad hack) * Added #define UPD_PLAY_STATUS 0x00000800 to guiUpdate.h * now AudioCDView uses UPD_PLAY_STATUS to draw the cursor and update the buttons, ... My idea is to create a new cursor for playing, and show the position in the play toolbar. This way we can set the marker even while playing, set selections, zoom, ... we just need to care of funcs that _change_ the Toc object. Why don't we use a fixed timeout for playing instead of the idle timeout ? Also, why are we doing this?: (now this is in AudioCDProject::AudioCDProject) soundInterface_ = new SoundIF; playBuffer_ = new Sample[playBurst_]; soundInterface_ = NULL; we create a SoundIF and then we lost the reference... why? This code also was in MainWindow.cc when there was a single-document, single-view. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
|
From: Andreas M. <an...@da...> - 2001-08-07 05:46:38
|
Manuel Clos wrote: > > Here is what I just commited to CVS: > > * Changed the play/stop button to a "play | stop" toolbar, this prevents > the "playing again" problem when you hit the button twice to stop the > playing and it starts again... > * moved the play and playCallback funcs to AudioCDProject > * added a playStop func to audioCDView and AudioCDProject > * got some icons from tcd for the play toolbar > * AudioCDView is no more a friendly class of AudioCDChild (read: removed > bad hack) > * Added #define UPD_PLAY_STATUS 0x00000800 to guiUpdate.h > * now AudioCDView uses UPD_PLAY_STATUS to draw the cursor and update the > buttons, ... > > My idea is to create a new cursor for playing, and show the position in > the play toolbar. This way we can set the marker even while playing, set > selections, zoom, ... we just need to care of funcs that _change_ the > Toc object. > > Why don't we use a fixed timeout for playing instead of the idle timeout ? It would be almost impossible to find the correct timeout value. If it is too small the timout will come before the playing function has returned. It it is too big the playing will be jumpy. I think the idle signal is the right choice. What advantage would you expect from the fixed timout signal? > Also, why are we doing this?: > > (now this is in AudioCDProject::AudioCDProject) > soundInterface_ = new SoundIF; > playBuffer_ = new Sample[playBurst_]; > soundInterface_ = NULL; > > we create a SoundIF and then we lost the reference... why? That's of course an error; probably an relict from some code changes. You can remove the allocation at this place. Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
|
From: Manuel C. <ll...@ja...> - 2001-08-08 00:29:21
|
Andreas Mueller wrote: >>Why don't we use a fixed timeout for playing instead of the idle timeout ? > > It would be almost impossible to find the correct timeout value. If it > is too small the timout will come before the playing function has > returned. It it is too big the playing will be jumpy. I think the > idle signal is the right choice. What advantage would you expect from > the fixed timout signal? Do you mean the idle signal comes just when there is no buffer no play? The two problems are: The application response (menus, ...) slows down when playing. And try this: zoom an audio project, play and then move the bar to show a new part, as the app is working the idle signal does not come fast enough and the sound cuts. I will play with timeouts a bit. I don't fully understand how the audio is played, so I will thank any explanation. Perhaps creating a thread for playing is a solution... >>Also, why are we doing this?: >> >>(now this is in AudioCDProject::AudioCDProject) >> soundInterface_ = new SoundIF; >> playBuffer_ = new Sample[playBurst_]; >> soundInterface_ = NULL; >> >>we create a SoundIF and then we lost the reference... why? >> > > That's of course an error; probably an relict from some code changes. > You can remove the allocation at this place. Ok. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
|
From: Andreas M. <an...@da...> - 2001-08-15 18:15:18
|
Manuel Clos wrote: > > Andreas Mueller wrote: > >>Why don't we use a fixed timeout for playing instead of the idle timeout ? > > > > It would be almost impossible to find the correct timeout value. If it > > is too small the timout will come before the playing function has > > returned. It it is too big the playing will be jumpy. I think the > > idle signal is the right choice. What advantage would you expect from > > the fixed timout signal? > > Do you mean the idle signal comes just when there is no buffer no play? No, it works that way: The idle signal calls the audio play callback which sends a chunk of audio data to the soundcard. While the callback is active the application is blocked. When the callback returns pending events are processed and after that the callback is started again by the idle signal. That's why I've chosen a small amount of audio data that is processed by the callback. After we've increased that to remove the audio jumping while scanning the application was less responsive. I think the right solution would be using threads but that would compilcate the program and I'm not sure if this worth the effort compared the results. Do we really have to provide perfect playing while editing the project. My original intention for the playback was to verify the edits you make to the project and not to entertain you during the work :) > I will play with timeouts a bit. I don't fully understand how the audio > is played, so I will thank any explanation. Perhaps creating a thread > for playing is a solution... Ok try that, maybe I'm missing something and this will really give a good solution. Regards, Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
|
From: Manuel C. <ll...@ja...> - 2001-08-16 17:38:28
|
Andreas Mueller wrote: > No, it works that way: The idle signal calls the audio play callback > which sends a chunk of audio data to the soundcard. While the callback > is active the application is blocked. When the callback returns > pending events are processed and after that the callback is started > again by the idle signal. That's why I've chosen a small amount of > audio data that is processed by the callback. After we've increased that > to remove the audio jumping while scanning the application was less > responsive. > > I think the right solution would be using threads but that would > compilcate the program and I'm not sure if this worth the effort > compared the results. Do we really have to provide perfect playing > while editing the project. My original intention for the playback > was to verify the edits you make to the project and not to entertain > you during the work :) :) Ok, You're right. We can leave perfect audio playing for a future release. Anyway I would like to not block editing, as the average user can't understand why he/she can't reorder tracks while playing (you can do this with most mp3 players). So at least this blocking should not be present the the (future) track list child. I'm currently working on making the CD duplication a project, this way you don't need a project or a chooser open. And this way you have access to menus (configuration, new project, open...). In the way doing this, I'm redesigning the interface a bit. The idea is to put the most used/simple features in front and the less in a dialog. I will also want to hide the "bus, id and lun" info in the CList, not remove them, but make it an options in the (still to be created) preferences dialog and default to hide them. People that like this info will be able to show it. Is there a standard way to get/set the reading speed of a scsi cdrom? I would like to be able to do so. Also for writing, I know we have already discussed this, but I have a clean solution now :). See you. -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
|
From: Andreas M. <an...@da...> - 2001-08-16 19:28:04
|
Manuel Clos wrote: > > :) Ok, You're right. We can leave perfect audio playing for a future > release. Anyway I would like to not block editing, as the average user > can't understand why he/she can't reorder tracks while playing (you can > do this with most mp3 players). So at least this blocking should not be > present the the (future) track list child. This is also quiet difficult to implement. The play function accesses the Toc and the subsequent Track objects. If you change the Toc object while other functions are accessing it (e.g. iterating over the tracks) we can easily come into situations which lead to errors and crashes. We would have to develop mechanisms that prevent that and I'm again not sure if this is worth the effort with the same arguments as in my last mail. If we popup the right message when a user tries to modify the project while playing I don't think it will be so hard to understand what's going on. > I'm currently working on making the CD duplication a project, this way > you don't need a project or a chooser open. And this way you have access > to menus (configuration, new project, open...). > > In the way doing this, I'm redesigning the interface a bit. The idea is > to put the most used/simple features in front and the less in a dialog. > I will also want to hide the "bus, id and lun" info in the CList, not > remove them, but make it an options in the (still to be created) > preferences dialog and default to hide them. People that like this info > will be able to show it. Ok, good idea. We should also hide the 'Add Device' box in a separate dialog and place the 'Add' button right beside 'Rescan' and 'Delete' as you already suggested. > Is there a standard way to get/set the reading speed of a scsi cdrom? I > would like to be able to do so. Also for writing, I know we have already > discussed this, but I have a clean solution now :). For SCSI-2/mmc compatible drives we such a SCSI command that returns the maximum read and write speed. But there's nothing in common for the older drive models. What is the clean solution? Andreas -- Andreas Mueller Tel: +49 89 67808848 Ramsmeierstr. 1 Email: an...@da... 85579 Neubiberg, Germany |
|
From: Manuel C. <ll...@ja...> - 2001-08-16 23:02:46
|
Andreas Mueller wrote: >>Is there a standard way to get/set the reading speed of a scsi cdrom? I >>would like to be able to do so. Also for writing, I know we have already >>discussed this, but I have a clean solution now :). >> > > For SCSI-2/mmc compatible drives we such a SCSI command that returns > the maximum read and write speed. But there's nothing in common for > the older drive models. > > What is the clean solution? Quote from a 3/5/00 mail: > For most but not for all recorder models. Also think of the situation > that a user selected multiple recorders with different maximum speeds. > I guess the maximal maximum speed would be appropriate in that case. Yes, really and argument to not do it [:)] . --- Basically, letting the user to select 20x when the burner is only 8x makes no sense. If we can't get the max recording speed then selecting the speed will work like now, but with a warning telling that we don't know what is the max speed for the burner (with the *don't show again* option, of course ;) ). Well, we now know the max speed, so let's say we have two burners, 4x and 8x. The user will have two options, use the max speed (max checkbutton) or use the max common speed if manually selected. Basically you can do this now, but you can also try to make both burn at 8x, which is wrong and will probably result in a coaster. If we know the max speed we can prevent the last. Selection of say 2x and 6x won't be available. I can't think of a situation. Anyway, you can't do this now :). Well, not a very clean solution :p, but will help users with "modern" recorders. Can we force the reading speed? Reading at a lower speed means less system load and better responsiveness. How do I get the max reading and writing speed? should we implement a method in DeviceList? Can cdrdao already set the reading speed? Can we specify multiple targets to cdrdao? or do we spawn different processes and the system cache does the work? I was also thinking of maintaining a feature list of cdroms/recorders, just like the current one but with more info, like firmware version (some recorders can write CDTEXT info after a firmware upgrade), ... but well, let's implement basic features first. Hope this is the last time I mess the duplicate cd dialog :D -- Manuel Clos ll...@ja... * Si no puedes hacerlo bien, hazlo bonito (Bill Gates) * If you can't do it well, do it nice (Bill Gates) |
Thanks for helping keep SourceForge clean.
X