Getting hiccup noise from Shoutcast - windows-phone-7

I'm trying to read Shoutcast stream and then play it using MediaStreamSource. Here is the excellent open source project that saved lot of my time. After little bit modification I'm able to hear perfect sound. But the problem is I'm getting a periodic blip/hiccup kind of noise.
Any idea how I can stop that noise. I thought its may be Shoutcast sends some metadata in interval but don't find out how to stop that. Tried with request.Headers["Icy-MetaData"] = "0";
But it doesn't fix my problem either. Any help will be greatly appreciated.
Edit1:
I did some more investigation. I read my stream data for 2-3 mins and found that there are lot of 'zero' byte in that stream. Here is the list of index of '0' byte
92 247 359 1208 1904 2037 2227 2397 2536 2694 2740 2863 2952 3048 3110 3689 3994 4027 4098 4218 4730 4830 4943 5029 5115 5248 5315 5358 5666 6084 6375 6873 6920 7441 7660 7700 7756 8174 8254 8614 9010 9018 9025 9039 9541 9846.....
Is it because httpwebrequest slow download/failed to download or Shoutcast itself sending those zero bytes? Also does this '0' bytes causing that hiccup noise?
Edit2:
Here is few line of code of how I'm getting response from shoutcast
HttpWebRequest request = result.AsyncState as HttpWebRequest;
HttpWebResponse response = request.EndGetResponse(result) as HttpWebResponse;
r = response.GetResponseStream();
ShoutcastHeader(r);
And here is my ShoutcastHeader method definition:
StreamReader headerReader = new StreamReader(r);
bool headerIsDone = false;
while (!headerIsDone)
{
string headerLine = headerReader.ReadLine();
if (headerLine.StartsWith("icy-name:"))
{
StationName = headerLine.Substring(9);
}
else if (headerLine.StartsWith("icy-genre:"))
{
Genre = headerLine.Substring(10);
}
else if (headerLine.StartsWith("icy-br:"))
{
BitRate = short.Parse(headerLine.Substring(7));
}
else if (headerLine.StartsWith("icy-metaint:"))
{
MetaInt = int.Parse(headerLine.Substring(12)) * 1111084;
MetadataAvailable = true;
}
else if (headerLine.Equals(""))
headerIsDone = true;
}
And here is the response in headerReader
ICY 200 OK
icy-notice1:This stream requires Winamp
icy-notice2:SHOUTcast Distributed Network Audio Server/Linux v1.9.93atdn
icy-name:Bollywood & Beyond - Radio NRI 24/7
icy-genre:Indian Hindi Tamil Telugu Malayalam Desi
icy-url:http://www.radionri.com
content-type:audio/mpeg
icy-pub:1
icy-br:128
Also I have places the stream bytes in my skydrive share location.

Based on this thread it looks like the hiccups are the header information being resent periodically. There is an issue on ShoutStreamSource project referencing this too:
"The current implementation does not discard the mp3headers after the first one has been parsed. This causes hicups in the sound coming from the stream, and will be fixed in the near future."
However at the time of this answer it looks like the project was put on hold. Hopefully you or someone else can add this functionality. At least knowing what the problem is should help with a solution.

Related

Spring Boot 2: Serving Mp4 videos with support for Range

I'm trying to stream Mp4 videos on my website, and support Range so you can easily navigate large videos without having to download the entire thing. Sadly for whatever reason sometimes the entire video up to the point you select is downloaded. It's like Range works half of the time
#GetMapping(value = "/videos/{fileName}", produces = "video/mp4")
public ResponseEntity<FileSystemResource> streamFile(
#PathVariable("fileName") String fileName) throws MalformedURLException {
String clipid = fileName.split("\\.")[0];
final Video video = videoService.getVideo(clipid.trim());
if (video == null) {
return ResponseEntity.status(HttpStatus.NOT_FOUND).body(null);
}
return ResponseEntity.ok().body(new FileSystemResource(video.getFile()));
}
The responses from the server:
First position move, GOOD:
Request: range: bytes=218202112-
Response: Content-Range: bytes 218202112-596696593/596696594
Second attempt to move the time position, Full download:
Request: range: bytes=365658112-
Response: No content Range, only length
So strangely enough, the issue was brought on by Cloudflare's cache system.
To fix it I simply created a page-rule to bypass caching on my video endpoints.

Video - stream slow using s3 content store

Video - stream - this works.. however on larger files it is slow..
How can I improve the content s3 store to deliver the content faster ?
I have tried returning a byte array and copy to a buffer.. all load.. just slow... I am not sure where the bottle neck is coming from..
Optional<File> f = filesRepo.findById(id);
if (f.isPresent()) {
InputStreamResource inputStreamResource = new InputStreamResource(contentStore.getContent(f.get()));
HttpHeaders headers = new HttpHeaders();
headers.setContentLength(f.get().getContentLength());
headers.set("Content-Type", f.get().getMimeType());
return new ResponseEntity<Object>(inputStreamResource, headers, HttpStatus.OK);
}
also get this warning:
Not all bytes were read from the S3ObjectInputStream, aborting HTTP connection. This is likely an error and may result in sub-optimal behavior. Request only the bytes you need via a ranged GET or drain the input stream after use.

How to send an RTS 802.11 packet using Scapy (and get a CTS response)

I'm quite new to Scapy, and I'm trying to craft an RTS packet and send it to an AP, in order to get a CTS response. However, I'm having a really hard time figuring out the proper way to do it (being a beginner in networking and 802.11 packets doesn't help either).
This is the code I have for now:
bytes = struct.pack("<H", 123) # 123 microseconds
timeval = struct.unpack(">H", bytes)[0]
pkt = RadioTap()/Dot11(addr1 = target_addr, addr2 = my_addr, type = 1, subtype = 11, ID = timeval)
I know that type must be equal to 1 since it's a Control packet, and that subtype must be equal to 11 because it's an RTS packet. However, when I send the packet with either sr() or srp() or sr1() I either get no response back (Scapy waits for a response but nothing gets back so it just continues waiting) or I get the exact message I sent.
This question mentions adding a Dot11Elt() layer at the end, however that changes nothing in my case.
This is the type of response I get back:
And if I open the 0th element of the response tuple with Wireshark, I get:
I've hidden the MAC addresses, but they are the sameas those I put in the packet I sent to the AP (target_addr and my_addr). I'm expecting to get back a CTS with my_addr as "destination address".
What am I doing wrong?

CAPL Multiframe handling

I am writting a CAPL for Diagnostic request and response, I can get response if the data is up to 8 bytes, if data is multiframe I am not getting respone and the message on the trace is "Breaking connection between server and tester", how to handle this? I know about the CANTP frames but in this case it should handle by CAN/Canoe .
Please read CANoe ISO-TP protocol. In case of multiframe response, the tester has to send the flow control frame which provides synchronization between Sender and Receiver, which is usually 0x30. It also has fields for Block size of continous frames and seperation time. Try the below CAPL code.
variables
{
message 0x710 msg = { dlc=8,dir = rx };
byte check_byte0;
}
on message 0x718
{
check_byte0 = this.byte(0) & 0x30;
if(check_byte0 == 0x10)
{
msg.dword(0)=0x30;
msg.dword(4)=0x00;
output(msg2);
}
}
I was trying to send the request over a message ID in most gross form like 22 XX YY , which is a read DID request,this works well if the response is less than 8 bytes, if response is more than 8 bytes this wont work. so we need to use the Diagnostic objects for the request and response as defined in the CDD(or any description file) as used in the project.
If you are not using CDD, in such cases you need to use CCI (Capl call back interfaces), mostly that is necessary for simulation setups.

AWS multipart upload from inputStream has bad offfset

I am using the Java Amazon AWS SDK to perform some multipart uploads from HDFS to S3. My code is the following:
for (int i = startingPart; currentFilePosition < contentLength ; i++)
{
FSDataInputStream inputStream = fs.open(new Path(hdfsFullPath));
// Last part can be less than 5 MB. Adjust part size.
partSize = Math.min(partSize, (contentLength - currentFilePosition));
// Create request to upload a part.
UploadPartRequest uploadRequest = new UploadPartRequest()
.withBucketName(bucket).withKey(s3Name)
.withUploadId(currentUploadId)
.withPartNumber(i)
.withFileOffset(currentFilePosition)
.withInputStream(inputStream)
.withPartSize(partSize);
// Upload part and add response to our list.
partETags.add(s3Client.uploadPart(uploadRequest).getPartETag());
currentFilePosition += partSize;
inputStream.close();
lastFilePosition = currentFilePosition;
}
However, the uploaded file is not the same as the original one. More specifically, I am testing on a test file, which has about 20 MB. The parts I upload are 5 MB each. At the end of each 5MB part, I see some extra text, which is always 96 characters long.
Even stranger, if I add something stupid to .withFileOffset(), for example,
.withFileOffset(currentFilePosition-34)
the error stays the same. I was expecting to get other characters, but I am getting the EXACT 96 extra characters as if I hadn't modified the line.
Any ideas what might be wrong?
Thanks,
Serban
I figured it out. This came from a stupid assumption on my part. It turns out, the file offset in ".withFileOffset(...)" tells you the offset where to write in the destination file. It doesn't say anything about the source. By opening and closing the stream repeatedly, I am always writing from the beginning of the file, but to a different offset. The solution is to add a seek statement after opening the stream:
FSDataInputStream inputStream = fs.open(new Path(hdfsFullPath));
inputStream.seek(currentFilePosition);

Resources