This version plays Gapless for Engine#3 better than 0.9g. Actually, this must be just good ...

See also 0.9g for current issues. Tracks with Diacritical Marks just play fine though.

Do note that if it takes longer than 7-8 seconds to load a track (which may be so over 100Mbit ethernet with tracks over 8 minutes) Gapless Playback is not possible, and a gap will be audible with length depending on how much longer the track loads than the 7-8 minutes mentioned.
In a future release all will anticipate on the speed of loading.

If I was to decide, this version (per explicit means) is a tad more accurate; please let know if you disagree.

Hi,

This is all how it's supposed to work;
The Player Priotity is for the controlling mechanism and the Thread Priority is for the Audio Engine itself.

The Player Priority really shouldn't be higher than the Thread Priority, because the Audio Engine then may suffer from the Player's tasks. So both should be in proper balance towards eachother, and further act within the system as a whole.

The priority of the Engine with #3 currently can not be changed for two main reasons :
1. I thought it really wasn't necessary because whatever I do with the system, it keeps on playing, and to my ears the same;
2. I have to make something for that which is different from #1 and #2.

You could say it is about the latter ony, but this is not true; there are (or will be) many settings for #3 in the near future, and all what's happening in there, happens at the lowest level. This means that wrong treatment of priorities will hang your system or can even hang itself. So in the #3 environment there's much more to it, *and* it isn't necessary IMO.

My tests were in a "normal" environment, meaning that no other realtime prio tasks were running, and all I did to shoot at the engine was with Normal priority. But, all does mean that your Realtime prio of the Player really should not be so. In your (#3) case it should Normal. Which brings me to this :

Usually one would set the Player Prio lower than - or equal to the Thread Prio. Furthermore, one would set the Player Prio by itsef at least one tad higher than Normal. Just to cause the tracks are loaded, and the thing (the controlling mechanism) does kind of realtime what you order it to, or quickly enough anyway. Now, since with #3 the Thread Prio can't be changed, the least I should "provide" is that the Player Prio is not allowed to change as well.
In the very end, of course, I should allow for changing the Thread Prio afterall ... .

Ok ... nothing about "slow" ... just my bad ...

I found that effectively you have 1.5 seconds to load the track. This really would be too few for a 100Mbit network connection.
In the next version this will be solved.

Actually I do ...   
When (double) click would be used in order to get a track played, it would undo a made selection in the Playlist Area (maybe you didn't know, but you can do that).

Were you not Gappy Jack ? 

Hmm ... Never minding for now how it happened, you could investigate your sound device settings. I wouldn't know what to look for exactly, but start with thinking and knowing that not all audio devices allow for exclusive use, and that, for example, the changing of the primary audio device to a different one without you noticing it, could cause this.
Btw, it's really time that I allow for changing the device like #1 does.

I can't think of any other reason than mentioned above, except for something is going on with the exclusive use of your audio device itself. On that matter, do note the two checkboxed for that in the (I think) Advanced tab of the device, one of those allowing exclusive use for beginnings. If that one got unchecked ...

Peter

I don't know what you guys are doing to have all so slow. It seems kind of impossible to me that you can't read a, say, 70MB track in 5 seconds. Even over 100Mb ethernet that would be almost possible, let alone an internal SATA drive ...
Anyway, obviously I can test myself over ethernet, just to experience what you do, and I will sort it out.


This is actually strange. I have a hunch that something else is going on.
When the track is loading over the ethernet, does your disk lamp lit from the Vista PC (the one where the track is uploaded to) ? It should not of course, but does it for the duration of the loading, or consistently longer after that (after = when the disk lamp of the source disk stops litting (hehe)) ?


You may. I don't see a problem why not implementing that.

Thanks Russ.
Peter

Thank you Johan. And have a nice holiday !

Hi Dave,

Although you are right in all you say, it's really not an argument anymore since both diacritical and gapless stuff is near solved. Besides that, it is my personal meaning that things should be as elementary as possible. Oh, you can aggregate them as (and when) you want, but you can't go the other way around. Just think of the (one example of) the search facilities the OS just gives you today (Vista would be best at it) which obviously can work on tracknames only if you have them ...

As you know, I will create the support for cue files anyway, but please keep in mind that you'd be always depending on me (and my time) for whatever it is you want to do at the track level. Mayne, just for fun, try to explore the Vista search facility which in the end is a rather powerful query tool of which I still have to find the complete syntax. Otoh, it won't tell you much if the result is not a bunch of coverart to choose from.

Quite another thing is that I really am not bothered by the individual tracks, as long as they reside in their own (album) map, which would mean that you aren't either (hahaha). It just brings ultimate possibilities (today known, or maybe later ...).

Actually, something like this is the best option. This is "eSata" (external SATA), and should have the same speed as internal SATAII disks (which you most probably won't even have in your notebook).
A few remarks though :

1. If applicable, you must have two PC card slots in the laptop, when you need the other for Firewire (like you, Chris).
2. You must really find out whether the speed of the PC Card is okay, and ask for a guarantee of that.
3. Chance is 99% that a by this means connected disk will not be able to spin down after a (set) time of inactivity. Even the PC hybernating ("sleeping") will not incur for this (not much different with USB/Firewire connected disks btw).
4. Cables are usually 1 meter long, but can be 2 meters with pricey cables.

Then, nowadays, eSata connected disk arrays (or enclosures) exist. Note that these will work with eSata multipliers, which actually will devide the bandwidth. This is no problem because you won't be using two disks at the same time. You may use two logical disks at the same time, but this is provided by the two ports on the PC card both working at full speed if all is okay.

SATAII copies up to 300MB per second and is by far the fastest connection of all. Your 1 TB backup would effectively go in less than 3 hours now (theoretically in less than an hour).
In comparison, roughly, Firewire800 is 80MB/s, Firewire400 40MB/s, USB 2.0 48MB/s, Gigabit Ethernet 100MB/s, normal ethernet 10MB/s.

There is no reason the eSata enabled enclosures are more expensive than others, nor are the SATAII disks you'd want then.

Hi Chris,

Allow me to answer on behalf of Gerner (who is enjoying holidays) : Yes. He has connected them to Vista.
It is just USB, so I can't guess why or how it can't be Vista ready ...

Remember, in one of these, nowadays, you can get 2TB of storage space, as long as the supplier mounts those disks. 1TB (2x 500GB) should be the least that's possible.

Before you decide, please don't forget that USB is a relatively sloooooww connection. A backup of 1TB would really take a day !
For a laptop the best hussle free option would be Firewire800 I think. Note that Firewire is really like a network (similar to ethernet) and you can connect and expand disks as you want. BUT : I really don't know what happens if your sound is Firewire connected too (like you have). O dear ...

As long as a "hickup" is a small skip of the track, yes (but I must solve that). If it's a small piece of silence, no, I don't know about that.

Which of both do you mean ?

By the way, currently I give room for 5 seconds loading time for the track. This is too few for an USB disk and larger tracks. It is enough for SATAII and a full CD.
In a next version this will be approached more "intelligently", and for example anticipate on the tracklength (and a kind of self learning from the speed of the previously loaded track).

Jack,

Can you copy this behaviour ? I mean, when you start XX and use #3 from the beginning, I don't suppose this happens ?
I'd say that in your case #1 was in the way of #3, and #3 could not get the audio device exclusively because of that. Technically I must "forget" to free the audio device when #1 stops.

For Engine#3 (Vista bit perfect playback) decent Gapless Playback is now available.
Edit : As it appears now : "Decent" means the some tracks (CDs) follow rules which make a very small portion of the beginning of a track disappear. This will be solved in due time.

Note that when you load the tracks over a slow connection (like Ethernet) Engine#3 might "time out" and playback stops. But, in order to let this happen a track must be really large and slow to load. E.g. I cannot let it go wrong with a 60 minute track (but my connection is really fast ).
Please report if you encounter this anyway, or other anomalies now occurring.


Further changes :

• With Engine#2 and #3 it is and was not possible to change the playback cursor position (for #3 this will eventually happen); because of that, the cursor was disabled before, that causing very poor visibility of it. From now on the cursor stays enabled (hence better visible), but dragging it is not effective.
• In the Settings Tab all so far settings have been removed. This concerns :
  Gapless : Everybody wants gapless playback, and two tracks with gap just stay like that (like a settop CD player).
  Show Tooltips : Unchecking it did not work so far anyway, and IMHO the ToolTips did not disturb (because of the delay).
  The name for the coverart file : Did not work so far, and in a next release the player will sort it out automatically anyway.

Current "new" issues (not new really since 0.9f, but newly learned) :

• It is rather obvious that when you don't like a current Playlist (or an in there dreagged CD) you clear the area and load a new list. When doing that during playing, the currently playing track will remain (which is good). However, when the currently playing track finishes, it will be selected again for playback instead of the (newly dragged) next.
• A new version of XXHighEnd firstly started may loose the current settings (like Engine#); when this happens the length of the trackname is overlapped by the coverart picture. At stopping and starting XX one time this is "solved" until a next new version is installed, when this anomaly happens again.
• Edit : As it now appears, the tracks with diacritical marks again won't play with this version. This will be solved a.s.a.p.

Lastly, be aware of sound quality changes on Engine#3 with this 0.9g version opposed to 0.9f. If everything is as intended the SQ should not have been changed, but many things have been changed in the program.

If they are not in one box (hence one USB connection), it's my guess that you can't "span" them into one volume. But maybe others know better ?
And indeed, when you'd end up with 4 drives, that would be very inconvenient.

Btw, boxes for two drives exist for sure, and 2x 500GB would be a good price/value.
2x 1TB (which also exists since 6 weeks or wo) would be more "infinite" though ...