This turned out to be quite the project.  There were multiple problems in the way data was prepared for writing (audiowrite), in the way Octave was interacting with the external SNDFILE library, and with the way data read from a file was scaled back to "native" range (audioread).  I applied a changeset which fixes all issues and adds BIST tests to the stable branch here: https://hg.savannah.gnu.org/hgweb/octave/rev/5283c505f92b.

This will be a part of the next bug fix release of Octave.  Closing report.

This continues to get more complicated.  I can get the written output file to contain 0xFF if I change the bias and scale arguments to be 127.5.  However, I experimented with writing -1.0 using libsndfile API and the result is 0x01 rather than 0x00.  Maybe this is something about how WAV files are written, or maybe there is an additional bug in libsndfile.

@Imad:  Could you run this test in Matlab and upload the file.  That will really help clarify what the expected behavior is.

audiowrite ('tst.matlab.uint8.wav', uint8 ([0, 1, 2, 253, 254, 255]), 8000, 'BitsPerSample', 8)

In audiowrite, the translation from [0, 255] to the range [-1.0, +1.0] for passing to libsndfile is compressing the range.

First this code,

  if (args(1).is_uint8_type ())
    bias = scale = std::pow (2.0, 7);

which sets bias and scale at 128.  And then

for (int i = 0; i < audio.rows (); i++)
  {
    for (int j = 0; j < audio.columns (); j++)
      {
        double elem = (audio.xelem (i, j) - bias) / scale;
        data[idx++] = std::min (std::max (elem, -1.0), 1.0);
      }
  }

The value 255 is translated to (255 - 128) / 128 = 127/128 which is not 1.0.

P.S:
the audio file generated by matlab is file #47518
the audio file generated by octave is file #47519

Could you upload the Matlab-generated file?  That would help with testing.

Simple code to reproduce:

audiowrite ('tst_uint8.wav', uint8 (255:-1:224), 8000, 'BitsPerSample', 8)
y = audioread ('tst_uint8.wav', 'native')

The resulting vector is

y =

  252
  251
  250
  249
  248
  247
  246
  245
  244
  243
  242
  241
  240
  239
  238
  237
  236
  235
  234
  233
  232
  231
  230
  229
  228
  227
  226
  225
  224
  223
  222
  221

No samples are lost, but they are all shifted down by 3.

Marking as confirmed and changing the Operating System to "Any" since I can reproduce this on Linux.

The file is written incorrectly. (it parses values 253,254,255 to 252. and parse 0 to 1).
the main problem maybe in audiowrite function.

the problem with audiowrite function is that it do not encode 0,253,254,255 values as uint8() to the wav file.
to verify this I propose the following code:

% test audiowrite function for uint8 vector
Fs=8000;
f="test.wav";
y=[];
for k=1:32
  y(k)=256-k; %%%%% last 32 bytes in the field 2^8.
endfor
audiowrite(f,uint8(y),Fs,'BitsPerSample',8);% values 255,254,253 could not be writen into the file !!!!
audioread(f,'native') %% check results written to the file

note: the code above works well on Matlab thus encoding all uint8 valuse including 0,253,254 and 255.