HN user

TwistedWave

81 karma

thomas@[username].com

meet.hn/city/fr-Paris

Socials:

- linkedin.com/in/thomas-thiriez-438625

---

Posts2
Comments27
View on HN

Why wouldn't it be possible to mlock all the memory pages used by the real-time thread?

I do my best to do it on the application side. It would be nice if Apple's CoreAudio did the same.

If you mean that it is difficult to identify the pages used, that is true, but I found a great way to do just that. I keep track of all the pages I mlock(), list all the remaining pages, and mprotect them to crash if I accidentally access memory that was not mlocked. That helped me identify a couple of pages I forgot, such as the one that contains the __stack_chk_guard

And regarding the code pages, for some reason I get a permission denied error if I try to mlock them. Not sure why.

There is no mlockall() on macOS, but if there was one, I could delegate the real-time audio handling code to a separate executable, and call mlockall(). I would be guaranteed all the pages used by the real-time thread would be mlocked.

And by the way if you are interested in the report I sent to Apple, you can find all the details with the sample code to reproduce the problem there:

https://twistedwave.com/AudioGlitches.zip

From the association’s website, you can learn :

France/England swims are no longer permitted. When the French authorities permitted these they usually started from Cap Gris Nez.

I don't understand. In most of your samples, there is no bar in the first two bands. Does that mean that your samples are a multiple of 1 MB?

If your read/write rate is not constant, such as in the non-optimized file copy and you display the rate mod 1024 in the first band, I expect to see seemingly random bars that would not show any meaningful information. What am I missing?

Hi HN,

After making an OS X and an iOS version of TwistedWave, I have now made an Online version that works in a web browser.

All the audio is stored and processed on the server.

There is a small flash module used to record audio, but I will be happy to get rid of it as soon as we have a browser with support for the AudioWorkerNode.

I have also made an API so you can integrate it with your own web site.

Having list iterators carry a field pointing to their container wouldn't help you determine the number of objects between two iterators when you splice, which is what you need in order to maintain the object count.

Storing an index in the iterator would not be a solution either. That would mean updating the index in all the existing iterators when you insert an object in the list.

It boils down to:

> (* 4294967296 4294967296)

$1 = 0

My guess is that guile uses the native int type to store small numbers, and then switches to a bignums, backed by GNU MP when the native ints are too small. Maybe in that particular case, the check fails, and the computation overflows the native int.

Securing Ubuntu 14 years ago

I rely a lot on apparmor to secure an Ubuntu installation. It offers a very fine grained control on what processes are allowed to do, what files they can access. I find it more powerful and easier to setup than a chroot.

The goal of hashing the passwords is to not store them in plaintext in the database, in case the server is compromised. In your case, an attacker doesn't need the password, the hash is enough to login.