My WCF project uses Mtom and streaming, and set the MaxBytesPerRead to 32K (on client and server) but when I run
read = fs.read(buffer, 0, buffer.length)
it doesn't let me read more than 4096 bytes (4k) at a time (the 32K buffer doesn't fill up- it's padded with zeroes)
Is there any way I can stream my multi-megabyte file in chunks larger than 4K (please say yes) ???
4096 is the default size for the read buffer on a FileStream, which I assume is what your are returning. I am not really sure how the 4k limit is affecting you, but your alternative is to read the entire file into a MemoryStream and send it that way.
Related
I am trying to flash my yocto-generated image into a SAM9X60EK board but it's insanely slow, I think it's because of the write buffer size which is only 8KB (and the image is around 150MB) as shown below,
$ sam-ba -p serial -b sam9x60-ek -a nandflash -c write:microchip-headless-image-sam9x60ek.ubi:0x800000
Output:
Opening serial port 'ttyACM0' Connection opened.
Detected memory size is 536870912 bytes.
Page size is 4096 bytes.
Buffer is 8192 bytes (2 pages) at address 0x0030aca0.
NAND header value is 0xc1e04e07.
Supported erase block size: 256KB
or
Wrote 8192 bytes at address 0x00800000 (0.01%)
Wrote 8192 bytes at address 0x00802000 (0.01%)
…
…
Wrote 8192 bytes at address 0x0015c000 (99.83%)
Wrote 8192 bytes at address 0x0015e000 (100%)
Is there any possibility to make this process any faster?
You can try running this command before burning：
sam-ba -p serial -b sam9x60-ek -a lowlevel
I am reworking the programmer for the Olimex iCE40HX1K board (targetted towards a STM32F103 ma) where I also would like to implement the "SPI Slave" mode to configure an image directly into RAM without using the serial flash.
Looking at the Lattice "programming and Configuration guide" (page 11), it is noted in table 8 that a EPROM for a ICE40-LP/LX1K must be at least 34112 bytes. (which -I guess- means that the configuration-files can be up to that size).
However, all images I have (sofar) created with the icestorm tools are 32220 octets.
I am a bit puzzled here.
Can somebody explain the difference between these two figures?
Does the HX1K need a configuration-file of 32220 or 34112 bytes?
I don't know how Lattice arrived at this number. A complete HX1K bin file with BRAM initialization but without comment and without multiboot header is 32220 bytes in size. The (optional) multiboot header would add another 160 bytes (32220 + 160 = 32380). The lattice tools usually add about 80 bytes to the comment field (32220 + 80 = 32300). Whatever I do, all numbers I have are more than 1000 short of 34112.
I don't know if there is a maximum length for the comment. Maybe there is and 34112 is the size of a bit stream with a comment of maximum length?
34112 - 32220 = 1892. Maybe someone decided to add 8kB (8192 bytes) just in case, but that person accidentally swapped the first two digits? Idk..
If you don't care about comments or multiboot headers, then iCE40 1K bit-streams have a fixed size, and that size is 32220 bytes.
I am implementing USB as a host using OHCI to read the files stored in the Flashdrive. To read I implement the read(10) command in SCSI. The Logical Block address being the sector number. The following is an image of the command I send for read(10) to read LBA 0x0000-
http://i.imgur.com/ky4FHlm.png
I read 512bytes(size of one sector or 1 LBA)and the following is the output that i get for LBA 0x0000-
http://imgur.com/jL6OEjE
The bytes in the above image are not present any where on the pendrive, I checked that using HXD. Now, for testing I filled the pendrive to full capacity. If I read any other LBA, other than 0x0000, then I always get 512 bytes of 0x00.
Could anyone please tell me what the problem could be?
Am I supposed to execute some other command before I do a read(10) so that the USB sends me the right data maybe?
From my understanding I have put DPO, FUA and FUA_NV=0 and also RDPROTECT=2
I am currently looking to add Trick and Play functionality to HTTP Live Streaming (HLS) Server. For Trick and Play functionality to work, generally MPEG Transport Streams are pre-indexed. What is the general format of the Transport Stream Index files and how can I determine the I-frame in Transport Stream using the Index files?
I am using Transport Stream and Index file from here.
Each live555 TS index record is 11 bytes long:
- Record Type: 1 byte
- Start Offset: 1 byte
- Size: 1 byte
- PCR (integer part): 3 bytes (little-endian)
- PCR (fractional part): 1 byte
- Transport Packet Number: 4 bytes (little-endian)
Your sample is H.264 so the Record Type to look for is:
RECORD_NAL_H264_IFRAME = 9, // H.264
Source
How do I get all the information regarding the header of an audio file, so it can be displayed in a readable format like ASCII values?
The audio file maybe of any format, most preferably .wav format.
EDIT:- OS can be windows 8.1 or ubuntu. I actually have to understand all the properties of the file like whether it is mono or stereo, its encoding, etc. maybe specifically .wav file, i would say.
I have knowledge about the C++ language, so that would be better.
There is a very powerful command you can use in a bash script: sox.
To get all the info you need about a wav file, you just have to run:
soxi file.wav
and you'll get something like:
Input File : 'file.wav'
Channels : 1
Sample Rate : 8000
Precision : 16-bit
Duration : 00:02:08.40 = 1027236 samples ~ 9630.34 CDDA sectors
File Size : 2.05M
Bit Rate : 128k
Sample Encoding: 16-bit Signed Integer PCM
sox is available for Windows as well, although I have never used there.
You can use FFPROBE utility from FFMPEG: http://ffmpeg.org/
"ffprobe" gathers information from multimedia streams and prints it in human- and machine-readable fashion.
For example it can be used to check the format of the container used by a multimedia stream
and the format and type of each media stream contained in it.
Code
ffprobe -i <file_name>
ffprobe -i myfile.wav
Output will look something like this
Input #0, wav, from 'myfile.wav':
Duration: 00:04:16.88, bitrate: 16 kb/s
Stream #0:0: Audio: g729 ([131][0][0][0] / 0x0083), 8000 Hz, 2 channels, s16p, 16 kb/s
Output Explanation:
g729 is encoding type here.
16 kb/s is the bit-rate.
2 channels
Sample rate 8000 Hz
For detailed information
ffprobe -i <file_name> -show_streams