We Keep Coding

Playing media from byte stream in .net

I am developing application that receives media content(.mp3/.mp4/.avi) in form of bytes.
However, as WPF doesn't support playing media from stream, So I started with WMP.dll.
I am creating class library that receives media in form of bytes and media format and play media accordingly.
Referring Creating the WMP Programmatically, however, I didn't find method to pass bytes stream.
So My question is how do I play media from bytes using wmp.dll?
Edit: I am using WMP.dll using COM located at C:\WINDOWS\system32\wmp.dll

I've been through this process a long time ago ...
Basically I would advise you NOT to go down the WMP route at all. It's heavy, cumbersome and not very nice to work with. I encountered lots of issues along the way basically. Least of all it being feature rich (which it isn't).
The best solution I found and the one I'm still using now is a library called BASS from Un4SeenDevelopments.
This library is tiny < 100k and basically it's awesome. Never had a problem with it and it has it's own .NET wrapper that is a free download from the site.
The support is amazing and the compatibility via a massive selection of plugins and additional libraries is staggering.
Highly recommended for what you want to do.
"BASS is an audio library for use in software on several platforms. Its purpose is to provide developers with powerful and efficient sample, stream (MP3, MP2, MP1, OGG, WAV, AIFF, custom generated, and more via OS codecs and add-ons), MOD music (XM, IT, S3M, MOD, MTM, UMX), MO3 music (MP3/OGG compressed MODs), and recording functions. All in a compact DLL that won't bloat your distribution."

Create virtual file path from stream

I have a general question concerning C# & Windows API:
My task is loading a file from a document management system (DMS) and create a byte array from this file. From the developer of the DMS I got a dll which provides a method like this:
loadFile(int DocId, string PathToSaveFile);
Unfortunately the given dll does not provide me a method to deliver the requested file as a byte array or any kind of stream. Now my question, is it possible with C# to create some kind of virtual path which does actually not exists on secondary storage. Instead all bits and bytes written to this path are forwarded to me in a stream? The goal of my intention is to increase the performance as I don't have to write data to a hard drive.
I already searched a lot, but actually don't know the keywords I have to look for. Perhaps someone can give me a hint or just tell me that it is not possible at all.

It will depend somewhat on how the library will open the file and read the file. If it is using CreateFile then there is the potential that you could provide access via a named pipe. The path to a named pipe can be specified using \\.\pipe\PipeNameHere. In C# you can use NamedPipeServerStream.
However, I think the odds of the client application being compatible with this are relatively slim and would suggest creating a RAM drive that will be easier to implement and is more likely to work. A RAM drive will appear as a normal disk drive. You can save and load files to it, but it is all done in memory.

Use a stream as file?

I am working on a telephony application using a third party library to send audio across the wire.
This third party library only accepts a very specific wav format, and takes in the file as a filename path on disk. Our current audio files are not in this format. I can use NAudio to convert from our legacy format to this new format.
However, I don't really want two sets of audio files floating around.
What I basically want to do is take an NAudio.WaveStream and be able to pass it to the third party library without writing it to disk, because the library takes a path to a filename. If performance is bad, I will be forced to have multiple sets of audio files, but I would like to avoid this. I am not even sure what terms to Google.
Is this a use case for memory mapped files?

Probably not worth your while but if you're absolutely stuck with the 3rd party app and are against writing to disk you could create a virtual drive using a library like http://dokan-dev.net/en/. You could intercept the requests from the 3rd party app and stream the converted files to it as they were needed.
Saying that, I would probably take the hit on writing the files to a normal drive.
If nothing else it'll kick off your searches.

File Transfer with Maximum Speed on LAN

Almost all of file transfer softwares like [NetSupport, Radmin, PcAnyWhere..] and also the different codes i used in my application, it slows down the transfer speed when you send alot of small sized files < 1kb like Folder of a game that has alot of files.
for example on a LAN (ethernet CAT5 cables) i send a single file, let say a video, the transfer rate is between 2MB and 9MB
but when i send a folder of a game that has alot of files the transfer rate is about 300kb-800kb
as i guess it's because the way of sending a file:
Send File Info [file_path,file_Size].
Send file bytes [loop till end of the file].
End Transfer [ensure it received completely].
but when you use the regular windows [copy-paste] on a shared folder on the network, the transfer rate of sending a folder is always fast like sending a single file.
so im trying to develop a file transfer application using [WCF service c# 4.0] that would use the maximum speed available on LAN, and I'm thinking about this way:
Get all files from the folder.
if(FileSize<1 MB)
{
Create additional thread to send;
SendFile(FilePath);
}
else
{
Wait for the large file to be sent. // fileSize>1MB
}
void SendFile(string path) // a regular single file send.
{
SendFileInfo;
Open Socket and wait for server application to connect;
SendFileBytes;
Dispose;
}
but im confused about using more than one Socket for a file transfer, because that will use more ports and more time (delay of listening and accepting).
so is it a good idea to do it?
need an explaination about if it's possible to do, how to do it, a better protocol than tcp that would meant for this.
thanks in advance.

It should be noted you won't ever achieve 100% LAN speed usage - I'm hoping you're not hoping for that - there are too many factors there.
In response to your comment as well, you can't reach the same level that the OS uses to transfer files, because you're a lot further away from the bare metal than windows is. I believe file copying in Windows is only a layer or two above the drivers themselves (possibly even within the filesystem driver) - in a WCF service you're a lot further away!
The simplest thing for you to do will be to package multiple files into archives and transmit them that way, then at the receiving end you unpack the complete package into the target folder. Sure, some of those files might already be compressed and so won't benefit - but in general you should see a big improvement. For rock-solid compression in which you can preserve directory structure, I'd consider using SharpZipLib
A system that uses compression intelligently (probably medium-level, low CPU usage but which will work well on 'compressible' files) might match or possibly outperform OS copying. Windows doesn't use this method because it's hopeless for fault-tolerance. In the OS, a transfer halted half way through a file will still leave any successful files in place. If the transfer itself is compressed and interrupted, everything is lost and has to be started again.
Beyond that, you can consider the following:
Get it working using compression by default first before trying any enhancements. In some cases (depending on size/no. files) it might be you can simply compress the whole folder and then transmit it in one go. Beyond a certain size, however, and this might take too long, so you'll want to create a series of smaller zips.
Write the compressed file to a temporary location on disk as it's being received, don't buffer the whole thing in memory. Delete the file once you've then unpacked it into the target folder.
Consider adding the ability to mark certain file types as being able to be sent 'naked'- i.e. uncompressed. That way you can exclude .zips, avis etc files from the compression process. That said, a folder with a million 1kb zip files will clearly benefit from being packed into one single archive - so perhaps give yourself the ability to set a min size beyond which that file will still be packed into a compressed folder (or perhaps a file count/size on disk ratio for a folder itself - including sub-folders).
Beyond this advice you will need to play around to get the best results.

perhaps, an easy solution would be gathering all files together onto a big stream (like zipping them, but just append to make this fast) and send this one stream. This would give more speed, but will use up some cpu on both devices and a good idea how to separate all files in the stream.
But using more ports would, from what i know, only be a disadvantage, since there would be more different streams colliding and so the speed would go down.

Best way to implement audio playback

I'm working on an application that will read in file paths and play audio files. I'm trying to keep this as simple as possible--by using existing codecs and free/open utilities. I'd like some suggestions on the best way to do this. I've had two ideas, both involving FFmpeg:
Create a simple GUI that allows the user to read pass in file(s) to be played, and then a ffplay.exe process is run in the background to play the file(s).
Go more in-depth by just using libavcodec and basing my project off the functionality available with that.
There are only a few main goals I have for this.
Be able to read in and play multiple files without breaks between them
Start playback at an arbitrary spot (based on a percent of total duration) within the track
Stop playback after an arbitrary amount of time, and move to the next track
Which of my two methods seem the most practical for this project? Is there a better--or perhaps less feature-intensive--alternative to FFmpeg that you would suggest.
This is for a Windows application written in C#.
Edit: One of the reasons that I started with FFmpeg is that it can handle many file types, notably MP3, AAC, Flac.
Edit2: If the use of libavcode.dll is the best option, it would also be helpful to get some info on implementing that in C#.

The BASS audio library has C# bindings and works very well with common audio formats (e.g. MP3) with plug-ins for other formats (e.g. AAC).
However, for commercial development, you require a license to use BASS.