Flac and Audio CD Health Checks
 

In article , Jim Lesurf
wrote:
My next step is to have the program also generate veusz files. That
should make it easier for people to see the results as plots (similar to
what I get with !Tau for RO). Once that's done I'll write a help file
and release the program.

OK, I've now put up a Linux version of Flac_HealthCheck and made it
available from

http://www.audiomisc.co.uk/software/index.html

I've called it version 0.63 to aid 'synching' it with the RO version, but
it's the first Linux version I've produced.

I've included a Help file and the source code. There are also a couple of
webpages

http://www.audiomisc.co.uk/HFN/HealthCheck/CD.html
http://www.audiomisc.co.uk/HFN/HealthCheck/Flac.html

which show examples and explain in more detail how to interpret the
results.

The program is written as a ROX filer application, but can also be used by
execution in the usual ways. It gives output as csv files along with some
'loader' files to quickly plot the results using the Veusz scientific
plotting program. This means if you use ROX and Vesuz then one drag and
drop followed by one click on an icon will show graphs of the results. More
info in the Help file.

Hope people find it useful. Anyone who wishes is welcome ( encouraged! 8-]
) to do versions for other platforms they may use. I know my code is
rubbish, so I'm sure others can do better if they're interested. :-)

I'd say 'enjoy' but the sad fact may be that the results are depressing for
some files.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

A question occurs to me prompted by the way the Flack Health Check program
works. (And which I may also use for CD Health Check.)

In operations it relies on writing a tempory file, reading back its
contents, deleting the file, then repeating the process. The 'cycle' takes
somewhat less than a second per tempfile.

This is being written to an ext4 formatted SSD, but could, of course be to
other format/types of storage depending on the user's situation.

Given the bufferring which file systems use, do the files all actually get
written onto the SSD/HD? Or do they go to some kind of ram buffer and are
then deleted again before being actually written to the main part of the
SSD or HD?

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
A question occurs to me prompted by the way the Flack Health Check program
works. (And which I may also use for CD Health Check.)

In operations it relies on writing a tempory file, reading back its
contents, deleting the file, then repeating the process. The 'cycle' takes
somewhat less than a second per tempfile.

This is being written to an ext4 formatted SSD, but could, of course be to
other format/types of storage depending on the user's situation.

Given the bufferring which file systems use, do the files all actually get
written onto the SSD/HD? Or do they go to some kind of ram buffer and are
then deleted again before being actually written to the main part of the
SSD or HD?

(Depending on mount options) they’ll be buffered at least initially.
Whether the buffer gets flushed while the file is live would be
dependent on timing; I’m not sure if it’ll attempt to flush blocks
corresponding to deleted files if it didn’t flush them when live (you’d
hope not, though).

I’m more confident that there’ll be real writes corresponding to changes
the containing directory.

If your goal is to avoid physical writes if possible, then a tmpfs is a
good bet.

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

In article
wwvr3q9q7a0.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:

If your goal is to avoid physical writes if possible, then a tmpfs is a
good bet.

Is that something I can expect anyone who used my programs to either
already have, or be happy to setup?

I'd wondered about the above but didn't try it for the following reasons:

RISC OS provides a 'ram' filing system as standard and its reasonably
commonly used. So my RISC OS programs often also use it. Fast and avoids
any 'wear and tear' on hard discs. But there isn't anything obviously
like it on my Mint boxes (or earlier other distros). e.g. no 'icon' on
the backdrop saying 'ram' or 'tempfs' or any hint of a way in. Which
does seem to imply such stuff isn't for ordinary users.

To expand on that: I just checked my (Mint) laptop and it does have a
tempfs set up for /run. And inside that I find, for example, /run/usr/1000
directory that presumably for tempfiles associated with things being run
already for me as user 1000. I can create files, etc, in that when
operating as myself, so don't need to be root. Seems OK for me.

But can I take for granted that the bulk of others who might want to
use my programs also have something like that which I can easily and
reliably use? Ideally for me, a location with the same address for
all users, so I can just use that as the directory to put my tempfiles.

With my RO machines I just use a file with a name like ram::ramdisc0.$.fred
(RO is inherently single user). But what would I do that would 'run
anywhere'? Preferrably without any faffing about probing where a suitable
location might be for a stream of tempfiles.

At present I'm just repeatedly creating a file called (with impressive
originality!) 'tempfile' inside the application's directory. That's
trivially easy for me to do, but risks wear and tear, and may be slower
than a ram based location.

I've done a websearch on this but not found a 'how to' as yet that
makes this simple and clear. So some advice would be welcome as I would
prefer using ram / tempfs if I can understand it, and it's simple
enough for my limited understanding! :-)


Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
Richard Kettlewell wrote:
If your goal is to avoid physical writes if possible, then a tmpfs is a
good bet.

Is that something I can expect anyone who used my programs to either
already have, or be happy to setup?

A common configuration is for /tmp to be a tmpfs. People who don’t make
it a tmpfs presumably don’t care... Put another way there’s a limit to
how much policy your program should be setting; rather, it should be
following the user’s policy.

There are some things to get right if using /tmp.

1. If the environment variable TMPDIR is set, use that instead of /tmp.

2. Don’t use predictable filenames; /tmp is shared between multiple
users. (Get this wrong and you will introduce security problems.)

If you don’t care about the filename, the easiest policy is to use
tmpfile(). That’ll given you an anonymous file somewhere sensible.

If you do care about the filename, use mkstemp().

To expand on that: I just checked my (Mint) laptop and it does have a
tempfs set up for /run. And inside that I find, for example,
/run/usr/1000 directory that presumably for tempfiles associated with
things being run already for me as user 1000. I can create files, etc,
in that when operating as myself, so don't need to be root. Seems OK
for me.

/run isn’t really the right place for application temporary files.

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

On Fri, 22 May 2015 13:53:43 +0100, Richard Kettlewell
wrote:

Jim Lesurf writes:
Richard Kettlewell wrote:
If your goal is to avoid physical writes if possible, then a tmpfs is a
good bet.

Is that something I can expect anyone who used my programs to either
already have, or be happy to setup?

A common configuration is for /tmp to be a tmpfs. People who don’t make
it a tmpfs presumably don’t care... Put another way there’s a limit to
how much policy your program should be setting; rather, it should be
following the user’s policy.

There are some things to get right if using /tmp.

1. If the environment variable TMPDIR is set, use that instead of /tmp.

2. Don’t use predictable filenames; /tmp is shared between multiple
users. (Get this wrong and you will introduce security problems.)

If you don’t care about the filename, the easiest policy is to use
tmpfile(). That’ll given you an anonymous file somewhere sensible.

If you do care about the filename, use mkstemp().

To expand on that: I just checked my (Mint) laptop and it does have a
tempfs set up for /run. And inside that I find, for example,
/run/usr/1000 directory that presumably for tempfiles associated with
things being run already for me as user 1000. I can create files, etc,
in that when operating as myself, so don't need to be root. Seems OK
for me.

/run isn’t really the right place for application temporary files.

I don't know if it is the same in all OS, but for temp files I
generally use a word relevant to the programme plus the current
process ID number. This pretty much guarantees a unique name that
won't be used by anyone else.

d

Flac and Audio CD Health Checks
 

(Don Pearce) writes:
I don't know if it is the same in all OS, but for temp files I
generally use a word relevant to the programme plus the current
process ID number. This pretty much guarantees a unique name that
won't be used by anyone else.

Both are highly predictable values. If you’re not using O_EXCL then you
probably have a security vulnerability.

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

On Fri, 22 May 2015 14:26:17 +0100, Richard Kettlewell
wrote:

(Don Pearce) writes:
I don't know if it is the same in all OS, but for temp files I
generally use a word relevant to the programme plus the current
process ID number. This pretty much guarantees a unique name that
won't be used by anyone else.

Both are highly predictable values. If you’re not using O_EXCL then you
probably have a security vulnerability.

I wasn't really thinking of security - just avoiding a file name
collision.

d

Flac and Audio CD Health Checks
 

On Fri, 22 May 2015 13:53:43 +0100, Richard Kettlewell
wrote:

There are some things to get right if using /tmp.

1. If the environment variable TMPDIR is set, use that instead of /tmp.

I would add to that, if it isn't set, set it as pointing to /tmp

As a possibly interesting aside which may help some users of embedded
devices, some programs / programming environments have a need or use
of TMPDIR, for example PERL, but this may not always be well
documented. One of the reasons for GetIPlayer or cpan update failing
on embedded devices can be either this variable is not set by the OEM
firmware's default boot up, or else it points to a very limited amount
of on-chip ram. The following sequence of actions in a user post-boot
script can resolve this difficulty, where hard-disk should be
replaced by the normal means of accessing the hard disk of the NAS or
media player in question:
1 if [ ! -d hard-disk/tmp ] ; then mkdir hard-disk/tmp; fi
2 cp -a /tmp/* hard-disk/tmp
3 mount --bind hard-disk/tmp /tmp
4 export TMPDIR=/tmp

In stage 1, you could also have an else statement that cleans out old
files.
--
================================================== ======
Please always reply to ng as the email in this post's
header does not exist. Or use a contact address at:
http://www.macfh.co.uk/JavaJive/JavaJive.html
http://www.macfh.co.uk/Macfarlane/Macfarlane.html

Flac and Audio CD Health Checks
 

In article
wwvlhggrcx4.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:

1. If the environment variable TMPDIR is set, use that instead of /tmp.

2. Don't use predictable filenames; /tmp is shared between multiple
users. (Get this wrong and you will introduce security problems.)

If you don't care about the filename, the easiest policy is to use
tmpfile(). That'll given you an anonymous file somewhere sensible.

I'm not clear how that would work for my requirement. I'm using system() to
launch flac and have it put its output into a file which I specify by its
name. Then my main program uses that name to fopen() the file and read from
it.

AIUI tmpfile() will give me a file 'handle' (FILE*) but no name. How would
I use that as part of the command string for flac?

I did find a man page for tmpname() but having given the details it says to
"Never use it!".

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

In article , Don Pearce
wrote:
I don't know if it is the same in all OS, but for temp files I generally
use a word relevant to the programme plus the current process ID number.
This pretty much guarantees a unique name that won't be used by anyone
else.

I tend to do something similar for tempfiles in ram: when using RISC OS.

Security isn't really an issue there as RO doesn't have much anyway beyond
their only being one user! The only user is the root user. End of.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

In article
wwvlhggrcx4.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:

A common configuration is for /tmp to be a tmpfs. People who don't make
it a tmpfs presumably don't care... Put another way there's a limit to
how much policy your program should be setting; rather, it should be
following the user's policy.

If I understand that correctly it sums up one of the reasons for my
problem.

Under RO I'm used to ram: being the standard place for "temporary files
held in ram". But with the Mint boxes I have the temp 'device' seems to be
in /run, not /tmp. And presumably the assigned 'directory name' will vary
from one distro to another.

The other side of the problem is that I need a file *name* to get flac to
save its results to a file. Then have that name to get a handle to read the
contents (and delete the file afterwards) in my main program.

I'm used to getting a handle from a name. But AIUI tmpfile() would then
need me to get a name from the handle.

WRT mkstemp() I'm not clear if it gives the full pathname of the file. And
I had the impression that the file might then vanish as soon as flac quit
after saving it when run by a system() call, so leaving nothing for me to
read with my main program.

I'm sure I'm misunderstanding some of this, but saying the above helps
explain why so far I've not used this route. Its far more messy than the
approach under RO! ... even if that is for 'good reasons' in other terms.

/run did at least give me a subdirecory with the user's ID number to keep
accidental clashes between users apart. But even there I can't be sure of
the relevant directory being /run, not /tmp or something else. Or can I be
sure TMPDIR will tell me?

So far it seems simpler to just use the inside of the application
directory. But alas that means reading and writing to the hard disc on
which it may be stored. Hence my initial questions about 'wear' and
bufferring.

That said, with RO I sometimes give users the choice by letting them
set a path for temp files. I could do that to let them choose, but
it would make user setup more complex.


Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
Richard Kettlewell wrote:
1. If the environment variable TMPDIR is set, use that instead of /tmp.

2. Don't use predictable filenames; /tmp is shared between multiple
users. (Get this wrong and you will introduce security problems.)

If you don't care about the filename, the easiest policy is to use
tmpfile(). That'll given you an anonymous file somewhere sensible.

I'm not clear how that would work for my requirement. I'm using system() to
launch flac and have it put its output into a file which I specify by its
name. Then my main program uses that name to fopen() the file and read from
it.

AIUI tmpfile() will give me a file 'handle' (FILE*) but no name. How would
I use that as part of the command string for flac?

“If you don't care about the filename� means exactly that. It sounds
like you do care about the filename.

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
Richard Kettlewell wrote:
A common configuration is for /tmp to be a tmpfs. People who don't make
it a tmpfs presumably don't care... Put another way there's a limit to
how much policy your program should be setting; rather, it should be
following the user's policy.

If I understand that correctly it sums up one of the reasons for my
problem.

Under RO I'm used to ram: being the standard place for "temporary files
held in ram". But with the Mint boxes I have the temp 'device' seems to be
in /run, not /tmp. And presumably the assigned 'directory name' will vary
from one distro to another.

These paths don’t identify a particular kind of fileystem; they identify
what kind of files should be put there. In particular, /tmp (or
$TMPDIR) is a location for temporary file.

If the operator wants, or does not want, to use a tmpfs for temporary
files, that’s up to them. There’s no such thing as a path which is
guaranteed to be a tmpfs; what filesystems are used where is down to
local policy.

WRT mkstemp() I'm not clear if it gives the full pathname of the file. And
I had the impression that the file might then vanish as soon as flac quit
after saving it when run by a system() call, so leaving nothing for me to
read with my main program.

mkstemp fills in a template, so it gives a full path if you supply a
template that will give a full path. It doesn’t delete the file; that’s
for you to do when you’re finished with it.

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

In article
wwv1ti8r5fm.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:
These paths don't identify a particular kind of fileystem; they identify
what kind of files should be put there. In particular, /tmp (or
$TMPDIR) is a location for temporary file.

If the operator wants, or does not want, to use a tmpfs for temporary
files, that's up to them. There's no such thing as a path which is
guaranteed to be a tmpfs; what filesystems are used where is down to
local policy.

That sums up why I decided I couldn't use this method for programs I
release for others to use. Its a shame, though, because it potentially
means the programs are slower and may 'wear' the SSD/HD.

It seems a shame, though, given that RO makes this easy.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

In article
wwv7fs0r5oi.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:

"If you don't care about the filename" means exactly that. It sounds
like you do care about the filename.

I don't mind what filename is chosen. But I would need to know what it is,
once chosen. So it depends what you mean by "care". :-)

That said, on another level I don't care because I can just stick with my
existing approach. ;-

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

On 22/05/15 15:18, Jim Lesurf wrote:
In article
wwvlhggrcx4.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:

A common configuration is for /tmp to be a tmpfs. People who don't make
it a tmpfs presumably don't care... Put another way there's a limit to
how much policy your program should be setting; rather, it should be
following the user's policy.

If I understand that correctly it sums up one of the reasons for my
problem.

Under RO I'm used to ram: being the standard place for "temporary files
held in ram". But with the Mint boxes I have the temp 'device' seems to be
in /run, not /tmp. And presumably the assigned 'directory name' will vary
from one distro to another.

The other side of the problem is that I need a file *name* to get flac to
save its results to a file. Then have that name to get a handle to read the
contents (and delete the file afterwards) in my main program.

Do you really need to do it this way? It seems rather inefficient.
I would prefer to make use of pipes, and get flac to stream the output to stdout and the program to read it from stdin.

This would avoid the nasty mess of temporary files, and reduce the wear on any physical disk.

Flac and Audio CD Health Checks
 

On Fri, 22 May 2015 14:57:59 +0100, Jim Lesurf wrote:

In article
wwvlhggrcx4.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:

1. If the environment variable TMPDIR is set, use that instead of /tmp.

2. Don't use predictable filenames; /tmp is shared between multiple
users. (Get this wrong and you will introduce security problems.)

If you don't care about the filename, the easiest policy is to use
tmpfile(). That'll given you an anonymous file somewhere sensible.

I'm not clear how that would work for my requirement. I'm using system()
to launch flac and have it put its output into a file which I specify by
its name. Then my main program uses that name to fopen() the file and
read from it.

AIUI tmpfile() will give me a file 'handle' (FILE*) but no name. How
would I use that as part of the command string for flac?

I did find a man page for tmpname() but having given the details it says
to "Never use it!".

There are a couple of other ways to do this:

1) use a script to run flac and pipe its output directly into
your program like this:

flac inputfile | yourprogram


Your program will use a loop to copy bytes from flac's stdout stream
into a temporary file created using something like:

#include stdio.h
...
FILE flacfile = tmpfile();

This is a nameless file which will vanish when you close it or exit
from the program. You'd fill it by reading stdin and after that you
can reposition to its start by calling rewind() and read through the
file as many times as you want.

2) you can do more or less the same as above by using the fork/exec/wait
sequence instead of system() and read flac's stdout into a nameless
file created with tmpfile().

Sources like the aforementioned 'Lion book' give good guidance on
using fork/exec/wait


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

Flac and Audio CD Health Checks
 

On Fri, 22 May 2015 16:55:20 +0100, Jim Lesurf
wrote:

In article
wwv1ti8r5fm.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueX f87AxnpFoA.invalid,
Richard Kettlewell wrote:
These paths don't identify a particular kind of fileystem; they identify
what kind of files should be put there. In particular, /tmp (or
$TMPDIR) is a location for temporary file.

If the operator wants, or does not want, to use a tmpfs for temporary
files, that's up to them. There's no such thing as a path which is
guaranteed to be a tmpfs; what filesystems are used where is down to
local policy.

That sums up why I decided I couldn't use this method for programs I
release for others to use. Its a shame, though, because it potentially
means the programs are slower and may 'wear' the SSD/HD.

It seems a shame, though, given that RO makes this easy.

Jim

Can you wear an SSD this way? As I understand it they have an internal
OS that is constantly shifting the data around anyway, and putting in
some more from outside really doesn't make a great deal of difference.

d

Flac and Audio CD Health Checks
 

In article , Nigel Wade
wrote:
The other side of the problem is that I need a file *name* to get flac
to save its results to a file. Then have that name to get a handle to
read the contents (and delete the file afterwards) in my main program.

Do you really need to do it this way? It seems rather inefficient. I
would prefer to make use of pipes, and get flac to stream the output to
stdout and the program to read it from stdin.

It depends on the meaning of "need". I've done it this way because its the
way I've managed (so far) to understand well enough to get working. But I
appreciate it is messy and clumsy. Afraid I'm not a very good programmer,
so just go for what gives me the required coconut.

I've been aware of pipes, but have no idea how I might actually use them in
this situation. If I can understand it, I may change to it in future. cf
my reply to Martin on this...

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

On 23/05/15 10:45, Don Pearce wrote:
On Fri, 22 May 2015 16:55:20 +0100, Jim Lesurf
wrote:

In article
wwv1ti8r5fm.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:
These paths don't identify a particular kind of fileystem; they identify
what kind of files should be put there. In particular, /tmp (or
$TMPDIR) is a location for temporary file.

If the operator wants, or does not want, to use a tmpfs for temporary
files, that's up to them. There's no such thing as a path which is
guaranteed to be a tmpfs; what filesystems are used where is down to
local policy.

That sums up why I decided I couldn't use this method for programs I
release for others to use. Its a shame, though, because it potentially
means the programs are slower and may 'wear' the SSD/HD.

It seems a shame, though, given that RO makes this easy.

Jim

Can you wear an SSD this way? As I understand it they have an internal
OS that is constantly shifting the data around anyway, and putting in
some more from outside really doesn't make a great deal of difference.

d


I would not worry about SSD wear - I have been using them in laptops for
a while - my current one is over a year old and shows 100% on the
Wear_Leveling_Count (that's good, 0% is "dead").

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
Richard Kettlewell wrote:

These paths don't identify a particular kind of fileystem; they
identify what kind of files should be put there. In particular, /tmp
(or $TMPDIR) is a location for temporary file.

If the operator wants, or does not want, to use a tmpfs for temporary
files, that's up to them. There's no such thing as a path which is
guaranteed to be a tmpfs; what filesystems are used where is down to
local policy.

That sums up why I decided I couldn't use this method for programs I
release for others to use. Its a shame, though, because it potentially
means the programs are slower and may 'wear' the SSD/HD.

I don’t understand your objection. As far as I can see you’re choosing
to avoid even the possibility of a tmpfs, on the grounds that you might
not actually get it. Which seems like cutting off your users’ noses to
spite their faces.

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

In article , Martin Gregorie
wrote:
On Fri, 22 May 2015 14:57:59 +0100, Jim Lesurf wrote:


AIUI tmpfile() will give me a file 'handle' (FILE*) but no name. How
would I use that as part of the command string for flac?

I did find a man page for tmpname() but having given the details it
says to "Never use it!".

There are a couple of other ways to do this:

1) use a script to run flac and pipe its output directly into your
program like this:

flac inputfile | yourprogram


Your program will use a loop to copy bytes from flac's stdout stream
into a temporary file created using something like:

#include stdio.h ... FILE flacfile = tmpfile();

This is a nameless file which will vanish when you close it or exit
from the program. You'd fill it by reading stdin and after that you
can reposition to its start by calling rewind() and read through the
file as many times as you want.


That looks like worth trying. However I'm not clear on details so would
like to check some points:

1) When calling flac using system() can I just replace the flac command's
final switch/setting

-o outputfile

with something like

inputfile | RunImage

(The program by default is being run with a process name 'RunImage',
although I can of course change that. Or can I get and use a process
number?)

Will the output be readable as a stream of bytes/chars I can use to fill a
buffer?

Will it pipe out until system() is done, so will be readable afterwards?

And is it the case that simply using

FILE flacfile = tmpfile();

will mean it will read as stdin when I use flacfile as the 'handle'?

Can I also use fread() of the correctly sized block rather than read as a
series of bytes/chars/etc?

Is there an example I can see of this? I'll do a websearch, but as yet
don't know anything about it!

Thanks again, this is interesting. I've know of the existence and general
pupose of pipes, but no idea how to use them.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

On Sat, 23 May 2015 09:45:45 +0000, Don Pearce wrote:

Can you wear an SSD this way? As I understand it they have an internal
OS that is constantly shifting the data around anyway, and putting in
some more from outside really doesn't make a great deal of difference.

'Constantly' is a bit rich - a block is only moved when flash memory
writes require it to happen. So the short answer is that every write to
flash storage reduces its remaining life.


--
martin@ | Martin Gregorie
gregorie. | Essex, UK
org |

Flac and Audio CD Health Checks
 

In article , Tim Watts
wrote:
Can you wear an SSD this way? As I understand it they have an internal
OS that is constantly shifting the data around anyway, and putting in
some more from outside really doesn't make a great deal of difference.

d


I would not worry about SSD wear - I have been using them in laptops for
a while - my current one is over a year old and shows 100% on the
Wear_Leveling_Count (that's good, 0% is "dead").

I'm not particularly worried about SSD wear as I've also (so far) used some
for years. But some of the people who use my program may be using
conventional spinning rust. And there *are* wear mechanisms for SSD
according to reports I've read. Just that in practice I (and many others)
don't seem to have run into problems with it.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

In article
wwvpp5rpql7.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:
If the operator wants, or does not want, to use a tmpfs for temporary
files, that's up to them. There's no such thing as a path which is
guaranteed to be a tmpfs; what filesystems are used where is down to
local policy.

That sums up why I decided I couldn't use this method for programs I
release for others to use. Its a shame, though, because it potentially
means the programs are slower and may 'wear' the SSD/HD.

I don't understand your objection. As far as I can see you're choosing
to avoid even the possibility of a tmpfs, on the grounds that you might
not actually get it. Which seems like cutting off your users' noses to
spite their faces.

"Objection" perhaps isn't the correct word. My concern is about how to let
the user employ it given that the 'locations' they have for tempfs may
vary.

FWIW I'm now experimenting with having my program use a tempfile whose
name is given via a user setting.

The default is to use the interal-to-application directory, as before. But
by giving an alternative that location and filename can be used.

So I've been trying

/run/user/1000/complicatedname

where the is a name that seems to be unlike the exising examples and
fairly randomised and long. But which also refers to the program name in
part. I can see there is a risk that the name may clash with that wanted by
something else. But I've tried to make the risk low.

This speeds up the program operation quite noticably. Particularly useful
for 'high res' files that can have hundreds of megs of LPCM to churn
though. (Note I'm doing this in 5-sec chunks, so the total temp storage is
more limited, but the end-to-end amount can be fairly high.)

However I did this because /run/user/ followed by my user id number seemed
a reasonably directory choice given that 'df' shows me its a tempfs
location mount *on my system*.

This mimics fairly well the approach I'm used to on RO.

*But* AIUI I can't assume that every user of every distro will have *that*
place 'free and available' as a ram-based temp storage they can user-acess.

So my "Objection" is in essence not being able to rely on a chosen
'location' name like /run/user. For RO I could in effect simply use 'ram:'
followed by a program-specific tempname (again settable by the user if
necessary).

Hence my current approach of allowing a user to pick a place if they wish
to have the tempfiles in ram. Or to leave as default if they're happy with
that.

That's about the simplest change my limited understanding makes possible at
this stage. It seems reasonable to me given that any user wouldn't need to
do anything if the default works and they are happy. If they want a faster
operation and dodge any 'wear' they can decide having used df and poked
about, where to choose.

But I will look at pipes.

All that said, if anyone else wants to do an improved version for their own
use or release, I'd be delighted. My interest is in the *results* I and
others can get. The program is a means to that end.

Once I've tested it a bit more and added relevant info to the Help I'll
make the tweaked version available. Then let any users decide as they
prefer.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
Richard Kettlewell wrote:
If the operator wants, or does not want, to use a tmpfs for temporary
files, that's up to them. There's no such thing as a path which is
guaranteed to be a tmpfs; what filesystems are used where is down to
local policy.

That sums up why I decided I couldn't use this method for programs I
release for others to use. Its a shame, though, because it potentially
means the programs are slower and may 'wear' the SSD/HD.

I don't understand your objection. As far as I can see you're choosing
to avoid even the possibility of a tmpfs, on the grounds that you might
not actually get it. Which seems like cutting off your users' noses to
spite their faces.

"Objection" perhaps isn't the correct word. My concern is about how to let
the user employ it given that the 'locations' they have for tempfs may
vary.

You’re looking at this completely wrong. People don’t have locations
for tmpfs. There’s no such concept. People have locations for
temporary files, and their own policies about how temporary files are
stored, based on their preferred tradeoffs between performance,
persistence, etc.

However I did this because /run/user/ followed by my user id number seemed
a reasonably directory choice given that 'df' shows me its a tempfs
location mount *on my system*.

It’s a terrible choice. /run is for pidfiles, sockets, etc. It happens
to be a tmpfs in some configurations but there’s no guarantee that this
will be true.

It’s not that long since /run didn’t even exist.

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

In article
wwvbnhbpixk.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:
"Objection" perhaps isn't the correct word. My concern is about how to
let the user employ it given that the 'locations' they have for tempfs
may vary.

You're looking at this completely wrong. People don't have locations
for tmpfs. There's no such concept.

Perhaps you missed my use of inverted commas. :-)

Would it help if I'd said locations in the filing system tree that are in
user accessible ram and use tempfs? If so, I'm happy to correct my wording.
Even if that wording is wrong, I hope that by now what I mean should be
clear.

People have locations for temporary files, and their own policies about
how temporary files are stored, based on their preferred tradeoffs
between performance, persistence, etc.

OK, please cf below on that.

However I did this because /run/user/ followed by my user id number
seemed a reasonably directory choice given that 'df' shows me its a
tempfs location mount *on my system*.

It's a terrible choice. /run is for pidfiles, sockets, etc. It happens
to be a tmpfs in some configurations but there's no guarantee that this
will be true.

Erm, that was actually one of the points I was making as a reason that made
this problematic for me. And hence why any such choice would be a user
option they'd have to make *if* it suited them. They'd have to decide what
alternative to /run.... suited them for they system.

It's not that long since /run didn't even exist.

The fact that it is 'new' doesn't seem like a reason for never using it.
However...

So what would you suggest in terms of a filing system address like
/run/user.... ? If your answer is "none of them" then I will stick with
what suits me and leave others to do what they prefer. But if there is a
common and recommended 'location', I can use it.

I must admit that I find it curious that despite the very logical
"everything is a file" approach of *nix that it seems to lack a standard
filing system address like /ram which gives the individual user some of
their own user space on ram. Its a standard feature of RO which is a minor
OS in comparison to Linux. It seems strange no-one has picked up on the
idea as being useful for users of Linux who aren't highly experienced
programmers. Or have they, but I don't know the address to use? Being so
used to the simple convenience of RO 'ram:' (and memphis) it seems an odd
situation.

However all that said. No-one is compelled to use any of the programs I've
written. No-one who uses this example is compelled to take up the option.
No one who does is forced to use /run/user/1000/whatever as the tempfile
'directory'. etc. And anyone who wishes is very welcome to do what they'd
feel is a "better" version if they want. At all levels they can make their
own choices.

As I've said, I'll try to learn about pipes, etc. And I may change when I
learn more. But the reality here at present is that what I've done seems to
work nicely for my purposes. And I thought one of the strengths of Linux is
that we can each use the system as we prefer.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
So what would you suggest in terms of a filing system address like
/run/user.... ? If your answer is "none of them" then I will stick with
what suits me and leave others to do what they prefer. But if there is a
common and recommended 'location', I can use it.

As I said, use $TMPDIR if set, otherwise use /tmp. It’s a standard
location for temporary files and is often a tmpfs.

If you want your own /tmp to be a tmpfs, do that.

If you want a guarantee that your program will always have a tmpfs
available at some predictable location: sorry, you can’t have one.

As I've said, I'll try to learn about pipes, etc. And I may change
when I learn more. But the reality here at present is that what I've
done seems to work nicely for my purposes. And I thought one of the
strengths of Linux is that we can each use the system as we prefer.

You can do what you like, as I believe I’ve already said. But if you
want your program to integrate well with other people’s systems, there
are right and wrong ways to go about it.

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

In article
wwvzj4vnuuk.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:
Jim Lesurf writes:
So what would you suggest in terms of a filing system address like
/run/user.... ? If your answer is "none of them" then I will stick
with what suits me and leave others to do what they prefer. But if
there is a common and recommended 'location', I can use it.

As I said, use $TMPDIR if set, otherwise use /tmp. It's a standard
location for temporary files and is often a tmpfs.

I'll need to unpack that because of my ignorance.

My mint laptop (for example) has /tmp. But 'df' doesn't list it, so does
that mean its on the main SDD simply as a directory. i.e. *not* a tempfs
(or ramfs) on ram?

If you want your own /tmp to be a tmpfs, do that.

That I don't currently know how to do. Nor do I know if it might give a
problem for something else. There are already two directories inside /tmp.


If you want a guarantee that your program will always have a tmpfs
available at some predictable location: sorry, you can't have one.

I take it that by "can't" what you really mean is that "the user would have
to be willing to create one. Which in turn means I'd have to explain /
request that *if* I wanted them to use a tempfs"?

However I think I pointed out that I'm not saying they must have this. All
I've done with the new version of the program is allowed the user to
specify where the tempfiles will go. And by default this will be as before
- inside the actual application's directory. Personally, I will go on to
prefer a ram based tempfs, but others can easily do otherwise.

As I've said, I'll try to learn about pipes, etc. And I may change
when I learn more. But the reality here at present is that what I've
done seems to work nicely for my purposes. And I thought one of the
strengths of Linux is that we can each use the system as we prefer.

You can do what you like, as I believe I've already said. But if you
want your program to integrate well with other people's systems, there
are right and wrong ways to go about it.

It seems reasonable to me to give them the choice to do what they prefer.
That's what my new version does.

However for myself (and as a suggestion to others) it seems to me to make
sense to use tempfs for this program's purpose.

Neither of the above seem "wrong" to me. But others can choose what they
want.

To go on...

I've found that I can do something like

sudo mkdir -p /mnt/tmp

followed by

sudo -t tmpfs -o size=20m tmpfs /mnt/tmp

to create a temporary 20meg 'ram disc' mounted at /mnt/tmp

Is that a more sensible option for me (and others who want to get the speed
and avoid disc wear) to employ?

I've noticed that the /mnt/tmp then persists being listed over a power
cycle, but the mounting/creation of the 20meg tmpfs space seems to be
needed after each bootup. So on from that, I assume I'd need to add
something appropriate to fstab if I want to avoid having to do that every
time?

Again, does that not seem reasonable?

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
Richard Kettlewell wrote:
Jim Lesurf writes:
So what would you suggest in terms of a filing system address like
/run/user.... ? If your answer is "none of them" then I will stick
with what suits me and leave others to do what they prefer. But if
there is a common and recommended 'location', I can use it.

As I said, use $TMPDIR if set, otherwise use /tmp. It's a standard
location for temporary files and is often a tmpfs.

I'll need to unpack that because of my ignorance.

My mint laptop (for example) has /tmp. But 'df' doesn't list it, so does
that mean its on the main SDD simply as a directory. i.e. *not* a tempfs
(or ramfs) on ram?

In general, yes.

If you want your own /tmp to be a tmpfs, do that.

That I don't currently know how to do. Nor do I know if it might give
a problem for something else. There are already two directories inside
/tmp.

I don’t know Mint. But:

In Debian systems, historically, you could edit /etc/default/tmpfs and
set RAMTMP=yes. /tmp would be a tmpfs after the next reboot. In newer
Debian systems, with systemd, you’d enable tmp.mount.

On practically any Linux system adding a line to /etc/fstab should work.
Again, it would take effect after the next reboot.

Migrating to any different filesystem on /tmp without a reboot risks
breaking the running things that rely on it, hence the general theme of
rebooting to turn it on.

If you want a guarantee that your program will always have a tmpfs
available at some predictable location: sorry, you can't have one.

I take it that by "can't" what you really mean is that "the user would have
to be willing to create one. Which in turn means I'd have to explain /
request that *if* I wanted them to use a tempfs"?

Yes. There’s no filename you can bake into your program that will
always be a tmpfs.

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

On 23/05/2015 12:55, Jim Lesurf wrote:
In article , Tim Watts
wrote:
I would not worry about SSD wear - I have been using them in laptops for
a while - my current one is over a year old and shows 100% on the
Wear_Leveling_Count (that's good, 0% is "dead").

I'm not particularly worried about SSD wear as I've also (so far) used some
for years. But some of the people who use my program may be using
conventional spinning rust. And there *are* wear mechanisms for SSD
according to reports I've read. Just that in practice I (and many others)
don't seem to have run into problems with it.

From what I've read, early flash memory cells had a limited life,
measured in thousands of writes, with unlimited reads being safe, while
new types have write lives in the millions of cycles due to improvements
in manufacturing techniques as the technology has matured. New ones also
have more redundancy built in, so the controller can transparently
replace failing cells with unused ones until the spares have all been used.

--
Tciao for Now!

John

Flac and Audio CD Health Checks
 

In ,
Jim Lesurf wrote:

A question occurs to me prompted by the way the Flack Health Check program
works. (And which I may also use for CD Health Check.)

In operations it relies on writing a tempory file, reading back its
contents, deleting the file, then repeating the process. The 'cycle' takes
somewhat less than a second per tempfile.

Is the file really necessary? If you want to avoid touching the disk
[1], the best way is to avoid using a file. Does the program that reads
the file need to seek around in it, or can it just read it serially? If
the reader and writer are separate programs use a pipe. If they're the
same program just use a RAM buffer. If the files are small enough to
consider using a RAM disk there's no reason not to just load the whole
thing into RAM anyway.

[1] AIUI that's the accepted spelling even in British English for
computer storage devices.

Flac and Audio CD Health Checks
 

In article , Tony Houghton
wrote:
In , Jim Lesurf
wrote:

A question occurs to me prompted by the way the Flack Health Check
program works. (And which I may also use for CD Health Check.)

In operations it relies on writing a tempory file, reading back its
contents, deleting the file, then repeating the process. The 'cycle'
takes somewhat less than a second per tempfile.

Is the file really necessary? If you want to avoid touching the disk
[1], the best way is to avoid using a file. Does the program that reads
the file need to seek around in it, or can it just read it serially?

I'm calling flac to read successive 5-sec chunks from a flac file. Each
time the flac utility will presumably have to seek.

I am aware there are many ways to do what I've done. However I've done it
so far in the way I found easiest and most familiar.

If the reader and writer are separate programs use a pipe.

I may have done if I'd known how to. But in practice I wanted to get a
program that produced the required coconut without too much delay. So far
as I'm concerned, the purpose of the programs I write are to produce a
result. It's nice to learn more about programming, but that's not my
main aim.

I still don't know in sufficient detail how to use a pipe for this. But I
do now know how to set up a 'ramdisc' for myself. Which strikes me as a
perfectly reasonably method - and one I'm familiar with from RO.

Note that - as I've already explained - any user of the program will be
able to choose whatever storage device and directory they wish for the
tempfiles. And that anyone who wants can modify the program as they prefer.
Source code provided. So if someone wished - say - to make a 'load the
entire LPCM in one go' version, or one that pipes, that's fine with me.


If they're the same program just use a RAM buffer. If the files are
small enough to consider using a RAM disk there's no reason not to just
load the whole thing into RAM anyway.

Afraid I don't know the distinction here between a ram buffer and a ram
disc. And the files vary in (unpacked to LPCM) size. But sizes of 1GB or
more aren't unusual for the files I work on.

There is, perhaps, another point you will appreciate. I wrote this program
initially for RISC OS. So I'm essentially 'porting this to Linux' to give
the opportunity of any interested Linux user to perform the same analysis
on their flac files. Given this and my background I'm avoiding making
needless changes. TBH I'm hoping others will be interested and do a
'better' program for the task - and port to other platforms. My interest
is in the audio analysis. I'm not really much of a programmer. Given
that the Flac program works I'd feel it more productive to do the Audio
CD version once I'm settled.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

In article , Jim Lesurf
wrote:
sudo mkdir -p /mnt/tmp

followed by

sudo -t tmpfs -o size=20m tmpfs /mnt/tmp

to create a temporary 20meg 'ram disc' mounted at /mnt/tmp

I'm now trying to determine what I'd add to fstab to get a ramdisc. I've
looked on the web and found various *different* listed fstab lines for
this, so I'm unclear what the line should say.

e.g.

If I first do a

sudo mkdir -p /mnt/ramdisc

Do I add to fstab

tmpfs /mnt/ramdisc tempfs size=XXX 0 0

or

tmpfs /mnt/ramdisc rw 0 0

or

ramdisc /mnt/ramdisc tmpfs mode=1777,size=XXX

or

tmpfs /mnt/ramdisc tmpfs size=XXX,mode=0777 0 0

I've see all these suggested on webpages. Some look like synonyms with
different settings, but others don't.

So what's the recipy?

What I'd like is a ramdisc at /mnt/ramdisc which is of modest size and I
can use for temporary files.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
I've see all these suggested on webpages. Some look like synonyms with
different settings, but others don't.

So what's the recipy?

That depends what you want. Only you can decide that. ‘man mount’
describes the meaning of the options. On one system I have:

tmpfs /tmp tmpfs defaults,size=8G,nr_inodes=256k,nosuid 0 0

What I'd like is a ramdisc at /mnt/ramdisc which is of modest size and I
can use for temporary files.

NB tmpfs is _not_ a ramdisc; it is a filesystem that uses virtual
memory. The different from a traditional RAM disk is that there is no
underlying block device and its contents may be swapped out.

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

In ,
Jim Lesurf wrote:

In article , Tony Houghton
wrote:
In , Jim Lesurf
wrote:

A question occurs to me prompted by the way the Flack Health Check
program works. (And which I may also use for CD Health Check.)

In operations it relies on writing a tempory file, reading back its
contents, deleting the file, then repeating the process. The 'cycle'
takes somewhat less than a second per tempfile.

Is the file really necessary? If you want to avoid touching the disk
[1], the best way is to avoid using a file. Does the program that reads
the file need to seek around in it, or can it just read it serially?

I'm calling flac to read successive 5-sec chunks from a flac file. Each
time the flac utility will presumably have to seek.

Let's make sure I understand what's going on here. You want your program
to analyse a flac file and to do this you're using the flac utility to
decode that file into raw data your program can understand?

I am aware there are many ways to do what I've done. However I've done it
so far in the way I found easiest and most familiar.

And because there wasn't really another way available in RISC OS.

If the reader and writer are separate programs use a pipe.

I may have done if I'd known how to. But in practice I wanted to get a
program that produced the required coconut without too much delay. So far
as I'm concerned, the purpose of the programs I write are to produce a
result. It's nice to learn more about programming, but that's not my
main aim.

I still don't know in sufficient detail how to use a pipe for this. But I
do now know how to set up a 'ramdisc' for myself. Which strikes me as a
perfectly reasonably method - and one I'm familiar with from RO.

You've gone to some trouble to learn how to make a RAM disc, you could
have spent that time learning about pipes. There are several drawbacks
to the RAM disc, eg requires root access to set up, no guaranteed safe
place to mount it, not portable to other types of Unix (eg Apple's OS
X), whereas pipes are the natural way to transfer data between programs
in Unix. It is more complicated than just calling system(), but it's so
fundamental there's almost guaranteed to be a decent tutorial in any
book about Unix programming.

If my assumption above is correct, you just need to do this, in place of
the system() call:

1. Create a pipe with the pipe() function.
2. Call fork(), and in the parent continue as before, except instead of
opening a file you can use fdopen() to read from the output of your pipe.
3. In the child replace stdout with the input to your pipe. I can't
remember exactly how to do that, but I think it's a simple function call
which will be explained in a tutorial.
4. In the child call one of the exec() family of functions to launch
flac, using its --stdout option. man system says execl() is its nearest
epquivalent, but it's worth looking at the others to see if one suits
your use case better. This basically replaces the child fork of your
program with flac, with stdout still hooked up to your pipe.

I'm not sure whether you were splitting the file into 5 second chunks to
avoid filling up a RAM disc, or because your aim is to analyse just 5
seconds at a time, but in the former case there's no need to do that
with pipes. You can just run one instance of flac on the whole file and
let the system handle the buffering.

Flac and Audio CD Health Checks
 

In article
wwvsiammhjn.fsf@l1AntVDjLrnP7Td3DQJ8ynzIq3lJMueXf 87AxnpFoA.invalid,
Richard Kettlewell wrote:
Jim Lesurf writes:
I've see all these suggested on webpages. Some look like synonyms with
different settings, but others don't.

So what's the recipy?

That depends what you want. Only you can decide that. 'man mount'
describes the meaning of the options. On one system I have:

tmpfs /tmp tmpfs defaults,size=8G,nr_inodes=256k,nosuid 0 0

Sorry, I'd assumed that from the context of the previous discussions it
would have been reasonably clear what I'd like. I said in an earlier
posting:

I've found that I can do something like

sudo mkdir -p /mnt/tmp

followed by

sudo -t tmpfs -o size=20m tmpfs /mnt/tmp

to create a temporary 20meg 'ram disc' mounted at /mnt/tmp

and that does what I want. But the second command needs repeating after
each bootup.

So my aim is to have this setup automatically via fstab, but I'd prefer a
name /mnt/ramdisc and a size of, say, 128m. I'd like that name because it
reminds me of what I can easily use for my RO programs where the data is
stored in ram.

cf below.

What I'd like is a ramdisc at /mnt/ramdisc which is of modest size and
I can use for temporary files.

NB tmpfs is _not_ a ramdisc; it is a filesystem that uses virtual
memory. The different from a traditional RAM disk is that there is no
underlying block device and its contents may be swapped out.

Yes, I'm aware it may get swapped onto other hardware at times. However
that's not likely to happen much with my systems as when I monitor that it
seems to almost never occur. And even if it does on rare occasion, that's
fair enough. I'm happy to regard any swapping as something I don't have to
notice for my simple programs.

I also realise there is a different Linux system with a name that could be
confused, and behaves differently. But I'm just doing this for my purposes
on my machines, aware of that.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html

Flac and Audio CD Health Checks
 

Jim Lesurf writes:
Richard Kettlewell wrote:
Jim Lesurf writes:
I've see all these suggested on webpages. Some look like synonyms with
different settings, but others don't.

So what's the recipy?

That depends what you want. Only you can decide that. 'man mount'
describes the meaning of the options. On one system I have:

tmpfs /tmp tmpfs defaults,size=8G,nr_inodes=256k,nosuid 0 0

Sorry, I'd assumed that from the context of the previous discussions it
would have been reasonably clear what I'd like. I said in an earlier
posting:

I've found that I can do something like

sudo mkdir -p /mnt/tmp

followed by

sudo -t tmpfs -o size=20m tmpfs /mnt/tmp

to create a temporary 20meg 'ram disc' mounted at /mnt/tmp

and that does what I want. But the second command needs repeating after
each bootup.

So my aim is to have this setup automatically via fstab, but I'd prefer a
name /mnt/ramdisc and a size of, say, 128m. I'd like that name because it
reminds me of what I can easily use for my RO programs where the data is
stored in ram.

So do that. What’s stopping you?

--
http://www.greenend.org.uk/rjk/

Flac and Audio CD Health Checks
 

In article , Tony Houghton
wrote:
In , Jim Lesurf
wrote:


I'm calling flac to read successive 5-sec chunks from a flac file.
Each time the flac utility will presumably have to seek.

Let's make sure I understand what's going on here. You want your program
to analyse a flac file and to do this you're using the flac utility to
decode that file into raw data your program can understand?

Yes. I call flac to have it read a portion of a flac file and generate an
output file that contains the 'decoded' LPCM values. That's launched by my
main program using a system(flac ...) call. The program then opens and
freads the file to examine and analyse the content. This process is then
repeated chunk-by-chunk until the entire payload of the flac file is done.



I am aware there are many ways to do what I've done. However I've done
it so far in the way I found easiest and most familiar.

And because there wasn't really another way available in RISC OS.

So far I understand, that's the case. However its the only way I've found
practical on RO which avoids me having to produce a flac-standard decoder
that reads directly.


You've gone to some trouble to learn how to make a RAM disc, you could
have spent that time learning about pipes.

I was actually looking into both. But found producing a 'ram disc'
relatively easy using the commands I outlined. Since that also fits nicely
with the RO original sources, I've used it successfully.

Jim

--
Please use the address on the audiomisc page if you wish to email me.
Electronics http://www.st-and.ac.uk/~www_pa/Scot...o/electron.htm
Armstrong Audio http://www.audiomisc.co.uk/Armstrong/armstrong.html
Audio Misc http://www.audiomisc.co.uk/index.html