Subject: Re: ALSA midi problems Was: Re: [linux-audio-dev] disk-based sampler:
From: Chris Baugher (baugher_AT_enteract.com)
Date: Sat Jul 15 2000 - 04:40:17 EEST
The patch worked! I was also able to decrease the value to 5000 without
causing the "resource unavailable" error. The response seems quite good
although I'm not a keyboard player so I might not be a good judge. As far
as the midi problem goes, I ran the following code to try to reproduce the
error:
int midifd;
char c;
struct sched_param schdp;
midifd = open("/dev/midi0", O_RDONLY);
memset(&schdp, 0, sizeof(schdp));
schdp.sched_priority = sched_get_priority_max(SCHED_FIFO);
if( sched_setscheduler(0, SCHED_FIFO, &schdp) != 0 ) {
perror("error setting SCHED_FIFO, ");
}
while(1) {
if( read(midifd, &c, 1) < 0 ) {
perror("Read error, );
}
printf("%d\n", c);
usleep(200000);
}
close(midifd);
If I use a sleep value of 200000 there are no errors, but if I go any
lower than that they start to appear. As you decrease the sleep time they
get more and more frequent, and they happen at regular intervals. The
output with usleep(150000) is:
Read error, : Resource temporarily unavailable
8
-2
-2
-2
Read error, : Resource temporarily unavailable
-2
-2
-2
-2
Read error, : Resource temporarily unavailable
-2
-2
-2
-2
Read error, : Resource temporarily unavailable
-2
-2
-2
-2
It's very strange. I suppose doing select() and a non-blocking read would
work but I don't see why that should be necessary. (Unless of course
blocking read is forever broken).
I've also noticed that the OSS emulation seems to work better than native
ALSA. With OSS emulation I can hold down a note and switch consoles and
only hear a small click. With ALSA native instead of a click the sound
becomes very distorted, almost like it's clipping really bad or something.
After this happens once it will continue to sound like this until the
program is restarted. Trying to set the fragment size on the command line
to something other than 128 gives:
ERROR: writeAudio, exiting. writeAudio :Invalid argument
Setting the fragment size using OSS mode works fine though.
So I think that's it for now. I'll keep hammering and see what I can
figure out.
Thanks!
Chris|
On Fri, 14 Jul 2000, Benno Senoner wrote:
> On Fri, 14 Jul 2000, Chris Baugher wrote:
> > Ok... I fixed the mlock problem, just needed to change the max voices and
> > streams.
> >
> > I tried putting different values for usleep in the MidiIn main loop and
> > found that usleep(150000) seems to work the best. Now when I hit a note I
> > can hear a sine wave corresponding to the pitch of the particular note.
> > The "resource not available" error stills appears occasionally but now I
> > can at least get a few notes out. If I make the usleep() time smaller the
> > error happens more often.
>
> can you please try this patch ( patch -p0 < this patchfile)
>
> --- midiin.cpp Thu Jul 13 13:31:51 2000
> +++ midiin-test.cpp Fri Jul 14 23:45:50 2000
> @@ -206,10 +206,10 @@
>
> i=0;
> while(1) {
> - res=read(midifd,&buffer[i],1);
> - if(res<0) {
> - perror("ERROR in read_midi_bytes: read");
> - exit(0);
> + while(1) {
> + res=read(midifd,&buffer[i],1);
> + if(res >=0) break;
> + usleep(20000);
> }
> d_printf("read_midi_bytes: char=%x dec=%d i=%d len=%d\n",buffer[i],buffer[i],i,len);
>
>
> it basically checks if the read() from the raw midi device was successful,
> if not it sleeps 20msec and retries until success , this will hurt MIDI timing
> but at least the application will not exit anymore.
>
> ALSA folks, do I have to use NON BLOCKING IO plus select() when accessing to
> raw MIDI in devices ?
>
> If this is true, is there any particular reason why the BLOCKING mode was
> removed. A blocking read() should be more efficient than select() plus
> non-blocking read() right ?
> Correct me if I am wrong plese.
>
>
> let us know
>
> Benno.
>
>
>
>
This archive was generated by hypermail 2b28 : Sat Jul 15 2000 - 05:08:38 EEST