View Single Post
  #54 (permalink)  
Old February 5th, 2007, 05:21 AM
traut traut is offline
Eager Mistic Beaver
 
Join Date: May 2006
Posts: 287
Quote:
Originally Posted by _gmureddu_ View Post
In concept (until it is ratified as a new USB device class, just like MSC [UMS]), MTP is FAR supperior for the purposes of a media player due to a number of things:
How much of this concept is used in reality?

Quote:
[*]No overhead to the host computer of controlling another device. It is not much of a burden on current hardware, but it frees the process as it enables a number of other things:
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.

Quote:
[*]Independency of filesystem, literally every implementator could use any (and I mean any) filesystem on the device, as the host computer is not responsible for that filesystem, but the DAP's firmware, so this opens the door to having much more robust and better suited filesystems for these devices (for instance, one with journaling to avoid database corruption, better suited to make out the most out of the available space [better block management], faster reads, etc)
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?

Quote:
[*]The device and the PC work more like a network connection, like a network share over SMB (Windows shares), where one computer sends a series of commands along with the files to the other computer. The same is the basic principle here, your computer sends a series of commands through this protocol to your device, receives the files, adds metadata to the database, etc, based purely on these commands. The computer is not responsible for anything else than sending these commands, the device is entirely responsible of their execution, and even better, their interpretation and allocation and organization of the files and data structures.
This means, that U10 MTP version can work as a player, while connected to the PC? My UMS version can't...

Quote:
[*]Gives the ability to better organize how a particular device works, with standard applications, the aim is to get the protocol into a new device class definition, so that any compliant OS and program could send commands to MTP devices just like virutally any OS is able to communicate with one another through the Internet using TCP/IP.
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.


Quote:
[*]With those bases, implementers can do pretty much anything. However this greatly depends on the implementation itself (not the protocol as such) and that the protocol gets ratified as a new USB Device Class, so implementation could be even wider.
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).
Reply With Quote