I'm writing an application in Java using the Java Sound libaray that will allow me to stream music from my personal library to whatever computer I'm on. It's going well. I've success streaming mp3s with the occasional crack or pop. However, on one of my test files, I experienced regular and frequent stop-and-go kind of behavior.
This, to me, says that I'm failing to put data in the SourceDataLine fast enough and that it's underflowing. Everything I've tried has not resolved this. I'm wondering if this has anything to do with how I'm getting the data bytes to begin with so I'm posting the method I'm using. That can be found here. The method I'm talking about is the top box. I'd modified it so that I'm getting the data, sending it over the network using Sockets, and writing it to the proper line on the client end.
Any ideas on what could cause this? I've tried reading up on audio files, but I'm not really making any headway into what would cause this. Thanks in advance.
Related
I have existing RPG4 programs with green screens, i would like to be able to call the rpg programs with Java and bypass the green screens.
I have done some research on this and IBM OAR (Open Access: RPG) keeps coming up. but i have not found a working example yet.
My goal is to create a web app to collect the the same information and feed it to the back end RPG
any help would be greatly appreciated
EDIT
Delete: You can't.
Insert: A beginner will need to master several complex new concepts before tackling this.
END-EDIT
At least, not without changing the RPG program. Web requests are processed by server jobs, which run in batch - they are not connected to a 5250 terminal. Because they aren't connected to a terminal, when the RPG program tries to open the display file, it will fall over because there's no terminal to attach to.
In order for this to work you'd have to alter the RPG program to not try display file I/O if called by a batch process like a Java app (although Java isn't necessary in this web scenario).
One way to change the RPG program is to use input parameters; if you have them, then don't try to open the display file, but stuff the input parameters into the fields where the display file would have done. Since a display file also outputs from the program you'd need to reserve some parameters for the output information as well. This could get very ugly if a subfile is involved, as there would be potentially thousands of parameters.
OAR comes into the picture because one can write an OAR handler that continues to use the same display file I/O operations, but to direct the actual I/O elsewhere, like STDIN and STDOUT for an HTTP type application. Jon Paris and Susan Gantner have written an article called Getting a Handle on RPG's Open Access which you might find helpful. It's in the July 2010 e-edition of IBM Systems Magazine.
Better perhaps is to extract the business logic in the RPG program, implement it as stored procedures which can be called by the web application via traditional ODBC / JDBC. One can write stored procedures in RPG, so that's not as hard as it might seem.
OAR is probably going to be your best bet....
However, every example I can think of that I've seen has resolved around building a handler to replace a printer file (PRTF) or physical file (PF).
Replacing a display file (DSPF) is a whole other ball game. Primarily because the 5250 protocol is an "intelligent" protocol; unlike dumb character type protocols such as used by ANSI/VT100.
It certainly can and had been done. If you have a single basic screen, you might be able to do it. But for a complex application with multiple screens and subfiles you'll probably have a tough time. Especially if you don't have a in depth understanding of the 5250 protocol.
I'd recommend you take a look at one of the vendor toolset designed to use OAR to replace a 5250 screen with a web page. Those vendors have put years of time and effort into developing the handler needed.
http://www.profoundlogic.com/solutions/rpg-application-modernization.html
https://asna.com/us/products/wings
You might find the following publication useful:
Modernizing IBM i Applications
Lastly note that ROA isn't the only option. There's an older technique, "screen scraping" in which your application basically emulates a 5250 terminal. It's simpler than a full ROA handler, but the end result is simpler also. IBM has it's own tool, HATS. And for instance Profound logic also has a tool, GENIE. But you could conceivably build your own screen scraper, the opensource TN5250J would probably be a place to start. But even this would be non-trivial.
You should use a mix of parsin json on the iseries(this eliminates the subfile problems), one good javascript framework( I've used Extjs) and The Apache server for I.
I've developed a HTTP services framework based on json parameters send directly from the browser using Ajax, processing each request with any ILE language program(mostly rpgle) and returning the result in pure json created inside the program. With this approach, you just send/receive business data, leaving the front-end to the Javascript framework.
Hope this helps. Contact me if you need more help.
I am writing an applet that I eventually want to put online so that my friends/family can use it. I have the applet running now locally, but in order to work properly it needs to read a .ser file in when the applet opens, and update that same file when the applet closes. The file is quite large (~180 MB), though I am working on paring it down.
What would be the fastest/most effective way to read/write this file in java? There is a lot of information out there on this and I have never done anything like it before, so it's a bit overwhelming. The class HTTPURLConnection seems like an option to read it, but not write it. Any free web hosting that I have seen will not allow a file that big to be uploaded.
The size of the file should hopefully go down substantially, it is a list of 2.8 million musical artists, many of which I'm sure nobody using the program will ever encounter, but if this program is to be effective, many artists will have to be stored, so the problem most likely remains the same.
Thanks in advance for any help
It sounds like it would be wise to keep this large data and the processing of it on your server instead of making the applet operate on it. That's because you would avoid each user downloading a large file and processing it. If you had a server side piece that the applet could call to get useful information from, then only your server would have to load it, write it, and process it. You could implement a Java servlet, or a PHP program to respond to http requests from your applet in a format that suits the data. I'm assuming that your server can handle either servlets or custom PHP (most can).
all i want is suppose i have same song named as song.mp3 and song.aac now i want my program to identify that they are same, i know this is non-trivail task to do.
so far i have tried fingerprinting audio using dejavu python library which produces 2 different fingerprints for our case song.mp3 and song.aac, hence it doesnt suit need of my program.
I also tried MD5 using FFMPEG but as expected it gives different hash for even same songs downloaded from different websites
Do you guys have any idea how do I proceed?
It would be even great to provide me step wise procedure and library to achieve my goal.
thank you
Audio fingerprinting is incredibly complex, and difficult to get right. You do not really want to come up with your own algorithm just like that, because it likely is much worse than established methods (being better than established methods requires doing some research ;-)).
One of the open source solutions for audio fingerprinting which I found is http://echoprint.me/codegen
You can use that in your application, either by calling directly into the libcodegen API, or by spawning subprocesses for audio analysis.
I need to build a APNS provider program for my app.
I was previously using PHP to do this trick and everything's been working fine thanks to the abstraction offered by dear PHP.
But now I have to handle this task in Java. I do not want to use 3-rd party library in my code-base since I really need total control and customization. While I am trying I quickly find It becoming way more bare-metal.
I barely know how to work with bytes in java. I searched on Google for quite a while only to find that the information about building APNS provider in Java is amazingly rare considering popularity of Java.
To be specific:
I got device token as String deviceToken. And payload in String(JSON format) payload.
How do I write them to outputStream to be in line with binary format required by Apple?
Thanks guys!
I dont know why you wanted to recreate the wheel, but you can check this source codes:
https://code.google.com/p/javapns/source/browse/trunk/src/javapns/communication/ConnectionToAppleServer.java
https://code.google.com/p/javapns/source/browse/trunk/src/javapns/notification/Payload.java (this is the actual payload)
In any case, instead of rebuilding everything you can download the project and extend some classes for specific things you want to do. But as far as I know, that lib is pretty much complete, I used it in 2 projects and it works pretty well.
I've been tasked with implementing large (2gb+) file uploads via a web browser. After evaluating various technologies, java applets seem to be the way forward (only one's which provide proper access to the local disk). I was wondering if anyone can recommend a 3rd party file upload app we can use as a base? requirements are
Decent UI, ideally we want something similar to facebooks photo uploader
Can handle large (2gb+) files
Resumable uploads
We beed the source to extend it to our needs (dont mind paying extra)
You're probably looking for JUpload.
Update: not sure if it has as nice of UI as you're hoping, but unless you want to build a custom solution like I have it's your best option.
Just a tip, maybe it is obvious, i don't know :P
It is nice to send the big file in chunks like 2mb, and on the server side you just append the bytes to the target file. The server knows what bytes it needs, and if a upload is aborted and continued later, the server can just send a message about from what bytes to start uploading the file again. Then we get resumability (is it a word? :P) and safety of large HTTP-uploads (since, in fact, we are sending many smuller uploads, and each upload is checked to be of the correct size on the server).
We wrote an implementation like this once with a Java-applet as the client and PHP on the server, I'll see if I can dig it out as a reference for you :p
Not really a solution : from experience you may bump into the following issues:
problems when uploading over HTTPs
problems uploading through proxies
Just wanted to make you aware of these two cases, for you to test when evaluating a solution.
Hope, you will get solutions for your prob over here.. http://jupload.sourceforge.net/