[linux-audio-dev] Shared memory?

Juhana Sadeharju kouhia at nic.funet.fi
Mon Jul 7 09:15:01 UTC 2003


Could anyone check the shmserver.tar.gz, compile it, and test
if you have the same problem? Additional instructions below.

I have though about why the shared memory freezes. It could be
that Linux copies the shared memory pages for each client:
one shared memory segment, multiple copies. Would locking
the memory help? Maybe, maybe not.

I know there are high performance applications using the shared
memory well (at least their authors may think so). But so does
my own alsashmrec works well too (so I thought). If there indeed
is a severe (a minor?) problem in the kernel, then in all these
application it may cause very short freezes (until read, write,
sleep, suspend, etc. call releases it). A jitter in updating
lock-free FIFOs on shared memory.

If you don't get it or otherwise cannot find out what is going on,
then where I should post this? Is there a list where the kernel
and shared memory experts are reading?

And hey, why shmget did not work? See shmalloc_named_get().

Best regards,

Juhana

Additional instructions and the previous mail.

1. Compile it without sleep(1) [ as in code below ] and without
fprintf with ggg's [ one could change that to "g" so that
screen does not go too fast ].
Then compile and test with sleep, and then test with fprintf with
"g".

2. First run shmserver in a terminal. Copy the mid value
(second value printed).

3. Then run shmclient in another terminal. Paste the mid value:
 % shmclient <midvalue>


>From: Juhana Sadeharju <kouhia at nic.funet.fi>
>To: linux-audio-dev at music.columbia.edu
>Subject: 
>Date: 	Fri, 4 Jul 2003 16:46:25 +0300
>Reply-To: linux-audio-dev at music.columbia.edu
>
>>From: Ralfs Kurmis <kurmisk at inbox.lv>
>>
>>Try out this example
>>Split it in seperate files
>>( Needs x )
>
>Hello. Thanks for the example, but I see some problems there:
>if the second process does not find the segment given by the key,
>you example makes two distinct segments. That is what happen with
>me. Because I don't have IPC_CREAT in the second process, my
>program simply fails instead of creating second segment.
>
>I got it working otherway, but there are severe problems.
>In client, I simply skipped the shmget() and queried
>immediately the segment with shmat() with the mid value
>printed by the server.
>
>The example mailed here used shmget() with IPC_CREAT.
>When I used IPC_CREAT for both server and client, as I expected,
>I got two separate shared memories. In fact, as I make the shared
>memory in shmserver which is run first, the shmclient should not use
>IPC_CREAT at all.
>
>It works, but while the server seems to fill the shared memory
>with increasing integer numbers, the client behaves strangely.
>I have this code in shmclient now:
>
>  k = -1;
>  for (;;) {
>    if (k != nums[1]) {
>      k = nums[1];
>      fprintf(stderr,"%i\n",k);
>    }
>    // sleep(1);
>    // fprintf(stderr,"ggggg\n");
>  }
>
>What should it do? It should ideally print the increasing numbers:
>5435, 5436, 5437, etc. With sleep(1) it prints a new value once per
>second. However, without sleep(1), it prints only one number and then
>does not print anything anymore. It looks like Linux does not update
>the shared memory, why?
>
>When the "ggggg" is printed (without sleep), the shmclient prints only
>one number and repeatedly the "ggggg". Why the shared memory is not
>updated in this? I remember I had a similar problem with old XWave
>software at 1998 with much earlier kernel version (now I have 2.4.18 of
>RedHat 7.3).
>
>This looks serious problem. It may be that nobody has noticed
>it because either one uses sleep() or read()/write() in an
>audio system. That is, your software may work, but the problem
>may degrage the performance (as it certainly did freeze the
>printing in my shmclient). Perhaps the problem may cause an audio
>engine never work as fully as possible.
>
>If you get the shmclient work while the sleep(1) is commented out,
>please let me know :-)
>
>http://www.funet.fi/~kouhia/shmserver.tar.gz



More information about the Linux-audio-dev mailing list