Quote:
Originally Posted by traut
How much of this concept is used in reality?
|
Ask both Microsoft and iRiver
Quote:
|
Originally Posted by traut
The overhead is still around, although it's taken over to the PC and protocol layer. Does anyone have some real numbers? How much is the protocol firmware size, e.g. of U10 MTP vs. U10 UMS? How much is the CPU load of UMS vs. MTP?[
What's the practical use, as long as you can't use the host U10 while connected to the PC?
... In fact I don't know yet which one of both parts is named as the host here - the Win PC or the audio player? I assumed that your host is the PC, since you named the audio player as a DAP. Concerning your explanations, I'd expect that both would be hosts.
|
I think here the key would be the overhead on the device, as PCs are more than capable of handling them both.
Quote:
|
Originally Posted by traut
who cares - as long as you can't use special advantages of a file system, there's no special benefit. Typical applications would rely on default file systems where the MTP stack is around. Optimized solutions would work without a file system at all, but would have dedicated and optimized operations for writing to different storage areas (due to the degradation of flash cells), for redundancy and error correction. This can be done for any transfer protocol.
I guess it's always a topic of the transfer protocol to encapsulate the file system on the host. You say you can't use other file systems via UMS?
|
Well, for starters different filesystems have different benefits and drawbacks. Just look around and virtually any modern filesystem is ways better than any of the FATs, which are still widely used by these types of applications... Not the best FS you can use on
any system, especially when it is so prone to corruption.
And yes, you can use any FS with MSC devices, provided the host OS has the driver for that FS. And since pretty much the only FS that has implementations on vritually any OS is FAT(12,16,32), that's what's mostly used on any kind of external storage. Hell, even some MTP devices use FAT16/32 for their filesystem.
Quote:
|
Originally Posted by traut
This means, that U10 MTP version can work as a player, while connected to the PC? My UMS version can't...
|
Means it could, just as long as the firmware permitted it, in other words, is a problem of implementation.
Quote:
|
Originally Posted by traut
This sounds like a major protocol overhead to me. I did not understand why you compared MTP and TCP/IP - I expected the difference is more like MTP and FTP.
|
FTP uses TCP/IP as its underlying means of communication. And no, it doesn't act like UDP, as (if you are familiar with it) TCP/IP adds some overhead on the
line as this protocol ensures all packets go through the line by means of confirmation packets (which in this case is necessary for MTP devices, otherwise, how would you, the user, know if all the files you sent actually got to your DAP?), UDP does not have this overhead, and that's the reason why it is more suited for things like VoIP and gaming. HTTP/FTP/SMB/NFS are all protocols that use TCP/IP as infrastructure.
Quote:
|
Originally Posted by traut
So it's a matter of implementation again, whether it's good or bad. Personally, I fell: If functionality is not given directly by taking the proper protocol, but will depend on further implementation, then it's less a matter of the transfer protocol, but of the firmware layer above. The question then is: What's the real blocker, which can't be done by e.g. UMS, which can be done by MTP.
I guess you are much more expert than I am. Maybe you could show how the actual benefits are implemented on the clix, the Zune or any other player, which could not be done via other transfer protocols (or how much more effort it would take to abuse another protocol for these functions).
|
Yes it all falls under the
implementation, ergo the
implementer's responsibility.
Actual implementations currently are lacking in one way or another, the main problem for MTP currently is not only how it is implemented, but rather its scarcity and lack of popularity.
The main thing that can be achived with MTP that can't be done with MSC (unless you used specialized apps) is the ability to use common software to perform synchronizations. Even though the protocol is implemented as part of WMP11, you can use other software to perform the synchronization (provided it "speaks" MTP) like WinAmp, MediaMonkey, etc. Yes means that you have to have installed some form of WMP to be able to have the driver... This is bitter-sweet, as now with Vista, all those PCs will have the necessary driver for MTP. That's Microsoft's choice how they implement (yes the darn implementation again) the driver on their platforms, and they've tied the protocol to WMP (not that you "can't get away with it" and install it stand-alone (I just don't know how would you go about that). So with MTP you can use any compliant software to sync, which also means that everything will be held into a metadata database for things like album, art, thumbnails, playlists, artist, title, year, etc, etc, all extracted from the metadata on the files themselves.