Hi I have just tested QFile::map() on Windows XP. On Windows the file is automatically locked against writes from other processes when it is mapped by one process.
----- I agree with Ilkka that we should pick a solid solution that covers also the rear use cases when a user uses Mixxx and a other allication with tag write capacity at the same time. Writing tags at Mixxx shutdown has some disadvantages in this case: * Mixxx always wins and may overwrites just changed tags with an earlier change done in Mixxx * It will delay the Mixxx shut down unexpected * There my be issues with removable media * There is a potential risk of data loss due to the (only theoretical ;-)) case of Mixxx crash. Using an external process for taglib has the following advantages: * a own process reduces the risk of corrupting the track by a Mixxx error elsewhere. * A crash due to a corrupt file does not effect Mixxx itself. This was reported by a Clementine developer, can be found by Google and I might remember that we had a mixxx bug like that. * we can use the advantage of file locks, at least at win XP. I have the hope that we can continue using QFile::map(). It might be the best balance between performance and resource usage because its in the OS domain. If not, it will be just simlpe to change to an in-memory caching. QBuffer buf = flie.readAll() But its even bedder to have also the control to the allocated memory as Ilkka pointed out. My favorite it to reuse the clementine-tagreader. It has a socket Interface to communicate with the host application and its based on taglib. It is an proved concept and already established. Using this we can easily reuse more clementine code like mass tagging and cover arts. (By the way: I fully agree with RJ, that Mixxx needs it own library and own GUI and that we have to be open for using Mixxx with any mediaplayer or track library tool.) Kind regard, Daniel -------- Original-Nachricht -------- > Datum: Mon, 2 Apr 2012 06:33:38 +0300 > Von: Ilkka Tuohela <ilkka.tuoh...@gmail.com> > An: Owen Williams <owilli...@mixxx.org> > CC: mixxx-devel@lists.sourceforge.net > Betreff: Re: [Mixxx-devel] Mixxx pissed me off today! > > As use cases go, I agree, nobody should be tagging tracks with exteral > programs while performing. On the other hand, changing the tag on mixxx screen > when you load the track is quite plausible, like in "Oh the artist tag is > wrong I'll fix it straight away!" use case. Some people also might use > itunes to look up songs while playing with mixxx, it's search has it's own > good points or someone might be more familiar with it. iTunes does not modify > tags itself unless you change something, so even this is not a problem as > such. > > I would even file a bug for easytag to fix the tag writing to use a > temporary file which is moved to correct name after updating tags, if they > don't > already do this. I think they already do this anyway. > > Myself, I run with the music library owned by root to prevent anyone from > messing up the files and only chown them to myself when updating > information intentionally, enough issues with commercial programs helpfully > writing > new tags or even corrupting the file to unreadable when I didn't ask them to > change it. When you have finished preparing your library, I can recommend > making editing it accidentally hard like this. > > About in-memory caching: > > I don't think the code to switch from mmap to in-memory caching would be > too hard to write, with configurable buffer size. It might be worth making a > branch with this to compare these two usage scenarios just to make sure. I > think it should use a fized size buffer for each deck, instead of trying > to allocate anything on the fly. > > Only problem I see with fized size in-memory buffers would be low-end > systems with limited memory, unless you calculate the buffer size and allocate > a buffer on-the-fly for each track: I would prefer here pre-allocated deck > buffers if this is done, but this may not work nicely if the laptop doesn't > have the memory available. Then again, 2 decks configured to play with > 128MB buffers each can be used to play about 11 minute long songs straight > from buffer and if the buffer size is configured in settings, it could be > adjusted to the expected maximum song length. The buffer size would normally > matter only to people who want to play a prepared full album mix, which of > course happens. > > As I said, I would prefer in-memory buffering over mmap, but then again > I'm always running on modern laptops with enough memory to give mixxx 2-3GB > without issues, and completely understand other use cases where this is not > possible or wanted. > > *hile* > > On 2 Apr 2012, at 06:05, Owen Williams wrote: > > > On Sun, 2012-04-01 at 22:29 -0400, Albert Santoni wrote: > > > >> This sounds pretty tricky. Would it simplify our lives if we dropped > >> mmapped I/O? (sorry Owen!) > > > > mmapped I/O was integral to preventing audio dropouts. Making that > > change resulted in the best improvement in sound performance. If we do > > have to drop mmapping, the replacement has to be an in-memory caching of > > tracks. > > > > That said, I still think it's incredibly unrealistic for users to be > > playing a track in Mixxx and also writing the tag of that track from > > another program. Can anyone imagine a scenario where, realistically, > > mixxx would be playing a track and something else would be writing that > > track? > > > > In-app, I think the best solution is delaying writes until shutdown / > > startup like RJ suggests. For users silly enough to use easytag or > > itunes while mixxx is running, they'll quickly learn not to do that :). > > > > owen > > > > > > > ------------------------------------------------------------------------------ > > This SF email is sponsosred by: > > Try Windows Azure free for 90 days Click Here > > http://p.sf.net/sfu/sfd2d-msazure > > _______________________________________________ > > Get Mixxx, the #1 Free MP3 DJ Mixing software Today > > http://mixxx.org > > > > > > Mixxx-devel mailing list > > Mixxx-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mixxx-devel > > > ------------------------------------------------------------------------------ > This SF email is sponsosred by: > Try Windows Azure free for 90 days Click Here > http://p.sf.net/sfu/sfd2d-msazure > _______________________________________________ > Get Mixxx, the #1 Free MP3 DJ Mixing software Today > http://mixxx.org > > > Mixxx-devel mailing list > Mixxx-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mixxx-devel -- Empfehlen Sie GMX DSL Ihren Freunden und Bekannten und wir belohnen Sie mit bis zu 50,- Euro! https://freundschaftswerbung.gmx.de ------------------------------------------------------------------------------ This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure _______________________________________________ Get Mixxx, the #1 Free MP3 DJ Mixing software Today http://mixxx.org Mixxx-devel mailing list Mixxx-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mixxx-devel
